Mostrando entradas con la etiqueta Programación. Mostrar todas las entradas
Mostrando entradas con la etiqueta Programación. Mostrar todas las entradas
Acceso root en un Motorola Dext y actualización a 2.1
Posted by raul_id on miércoles, 10 de noviembre de 2010
Muy buenos días queidos lectores. Vamos a darle un poco de vidilla al blog con un tutorial de esos que te dejan hacer cosas "malotas" a un de esos teléfonos que las compañías dejan de lado una vez te lo han vendido.
Hablamos del Motorola Dext, un androide como el que más, con un buen teclado físico y un interior bastante similar al del HTC Hero. Sin embargo, la compañía de la M no parece estar por la labor de dar soporte con actualizaciones más allá de la antidiluviana 1.5
Menos mal que a nuestro rescate aparecen los cocineros de ROM's a los que tanto tenemos que agradecer. Gracias a ellos, y con este tutorial podremos tener Android 2.1 update 1 en nuestro Dext.
Como es habitual en este tipo de tutoriales, debemos dejar claro que todo lo que hagas con tu teléfono es bajo tu propia responsabilidad....bla bla...bonito pisapapeles...bla bla...
Y dicho esto, aclarar que el siguiente texto ha sido escrito para ejecutarlo en Linux, probado en Ubuntu concretamente; pero a poco que conozcas Windows sabrás extrapolarlo al sistema del tito Gates.
-Preparativos previos:
·Debemos tener instalado el SDK de Android en nuestro Eclipse. AQUÍ una buena guía.
·Comprobamos que tenemos la herramienta ADB completamente funcional y comunicación PC/dispositivo. Supongo que YA LO SABÍAIS.
·Tener instalado en el Dext el Better Terminal emulator.
Obtener acceso Root:
Una vez tengamos todo listo en nuestro ordenador, vamos a descargar el archivo clave para obtener permisos de superusuario: Moto_MSM_Root
- Ponemos nuestro dispositivo en modo depuración (Ajustes-Aplicaciones-Desarrollo-Depuración).
- Conectamos el dispositivo por usb, pero sin darle a almacenamiento masivo desde el teléfono.
- Descomprimimos el archivo que nos hemos bajado antes (Moto_MSM_Root) en la carpeta Tools del SDK (ver tutorial de la herramienta ADB)
- Abrimos una terminal desde Linux y vamos hasta la carpeta Tools con "cd /home/usuario...."
- Comprobamos comunicación PC/dispositivo:
sudo ./adb start-server
sudo ./adb get-state
Si todo va bien nos dirá que existe comunicación con un mensaje que no sea "Unknow" o "unavaible".
- A continuación, sin cerrar la terminal, escribimos los siguientes comandos:
./adb push /su /sdcard/su
./adb push /rageagainstthecage-arm5.bin /data/local/tmp/rageagainstthecage-arm5.bin
./adb push /install-root.sh /data/local/tmp/install-root.sh
./adb shell (cambiará a modo shell con un $)
su
cd /data/local/tmp
chmod 0755 rageagainstthecage-arm5.bin
chmod 0755 install-root.sh
A continuación, con el teléfono aún conectado al ordenador abrimos Better Terminal Emulator en el dispositivo y escribimos en el:
cd /data/local/tmp ./rageagainstthecage-arm5.bin
¡No te pongas nervioso! Espera unos instantes y saldrá un mensaje tal que "Forked xxxx childs". Ahora podemos salir de la aplicación con la tecla Menú/Salir.
- Volvemos a entrar en la aplicación y vemos como ha cambiado el símbolo $ por #.
- A continuación teclea ahí mismo:
exit
exit
¡Enhorabuena! Ya eres Root.
Actualizar ROM:
No tan rápido...Antes de poder instalar ROM's no oficiales (o sí) debemos instalarnos un buen Recovery (algo así como un grub de un pc) y dependiendo de la versión del sistema Android, una Radio (cambiamos la versión del módem de telefonía).
Pero no os preocupéis, son pasos medianamente sencillos, vamos a ello:
Instalar Recovery:
Comprobamos que no haya ningún archivo .img en la raíz de la tarjeta SD del teléfono y nos vamos otra vez a ejecutar comandos ADB (recordad: terminal Linux y "cd ...a la carpeta Tools):
./adb shell (Nos pasará al símbolo $) su cd system mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system
- Descargamos el archivo del Recovery de AQUÍ.
- Lo descomprimimos y lo metemos en la raíz de la SD del Dext.
- Otra vez desde el ADB:
Recovery Instalada.
Instalar Radio:
- Descargamos la radio conveniente AQUÍ.
- SIN DESCOMPRIMIR lo metemos en la raíz de la tarjeta SD.
- Desenchufamos el teléfono del ordenador (Si no lo hacemos y apagamos se reinicia solo).
- Apagamos el Motorola Dext.
- Una vez apagado entramos en el Recovery manteniendo: Encender+Cámara (elegimos Recovery con los botones de volumen cuando nos salga)
- Elegimos la opción "Flash zip" y buscamos la radio que hemos metido anteriormente.
Radio Instalada.
Ahora si....instalar ROM:
Supongo que una vez llegados a este punto no querréis volver atrás, así que ¡vamos alla!. Para instalar ROM's nuevas no necesitamos más odiosas lineas de código, este (de verdad) es un proceso sencillo, simplemente...
- Descargamos la ROM que queramos y la metemos SIN DESCOMPRIMIR en la raíz de la SD.
- Entramos en modo Recovery.
- Recomendable hacer WIPE (dentro del menú del Recovery), con lo que resetea los datos del teléfono (NO DE LA SD)
- Flashear la ROM con la opción "Flash zip".
- ADLXMod (La probada durante este tutorial)
- J_r0dd’s CliqMod
FIN
¡Y hasta aquí llegamos! Espero que haya servido de ayuda, porque la verdad es que si no tienes experiencia en esto de "meterle mano" a Android puede que no todos los tutoriales que te encuentres esté todo bien explicado... Nos leemos!
R4ndom Frid4y #15: Lenguajes de programación esotéricos
Posted by Jose on viernes, 1 de octubre de 2010
Muy buenos días!! Hoy me gustaría hablar de algo que me pareció bastante curioso cuando lo conocí y que, quizás, os pueda molar: la programación esotérica.
El esoterismo en la programación nace como una vertiente que intenta crear lenguajes que vayan en contra de todos los principios de los demás. Es decir, mientras que lo que nosotros buscamos en un lenguaje de programación es un "relativa" sencillez a la hora de implementar nuestras aplicaciones, con esta vertiente de la programación nosotros tenemos lenguajes que se caracterizan por lo complicado de su utilización, sobretodo y entre otras cosas, por su limitado alfabeto.
Algunos ejemplos de este tipo de lenguajes que me he ido encontrando son:
- C-ofuscado
- Brainfuck
Para los que tengan curiosidad, aquí os dejo un enlace con un tutorial sobre este lenguaje. Además, como os será necesario un intérprete, yo lo he probado en Ubuntu, y existe uno en los repositorios oficiales (basta con sudo apt-get install bf).
Por último, aquí os dejo mi primer "programilla". Nos es más que el "Hola, mundo", pero a mi manera...
- Ook!
La principal gracia de este lenguaje es que la "palabra" Ook viene de la saga Mundodisco de Terry Pratchett (más de uno por aquí seguro que sabe lo que es esto), concretamente del bibliotecario, el cual originariamente era un mago pero, tras una magia fallida, se convirtió en un orangután, pudiendo únicamente articular Ook como sonido.
Aquí os facilito en Ook! el mismo programa que estaba escrito en Brainfuck. Existe un intérprete online de este lenguaje en esta dirección. Sin embargo, también se puede descargar el código fuente del mismo para ejecutarlo desde nuestro ordenador (aunque para ello necesitaremos tener instalado un intérprete de Ruby).
- Chef
Es una pena, pero con este lenguaje no he conseguido hacer nada especial. Aquí os paso el enlace Wikipedia en el que se habla un poco más, mostrando también el ejemplo básico del "Hola Mundo". Además, también hay en ese enlace un link a una página con un intérprete de este lenguaje escrito en Perl.
Espero que os haya gustado un poco este rollo/post que rompe un poco con lo que solemos hablar. Os animo a buscar más lenguajes como estos, como pueden ser Taxi (en el que imitamos una "carrera" de lo más típico para escribir el programa) o Shakespeare, también conocido como SPL, en el que creamos un programa imitando el guión de una obra de teatro.
Bueno gente, nos leemos!!!
BugBusters #3: Culturilla general
Posted by Ruro on miércoles, 14 de julio de 2010
Buenos y óptimos días.
En esta edición de BugBusters me gustaría ser, por primera vez en mucho tiempo, algo didáctico y hablar sobre algo que muy usualmente se confunde con los bugs, estos son los llamados glitchs. En términos llanos, la diferencia fundamental entre un bug y un glitch es que el primero afecta al desarrollo del juego negativamente mientras que el segundo no. Es decir, ¿recodáis aquel post del Dragon Age en que llegados a X punto del juego no se nos permitirá avanzar más? ESO era un bug. Un ejemplo de glitch sería la ciudad fallo de Pokemon o el propio Missigno (pero de esto ya hablaremos en otra edición que da para mucho), son más inofensivos en teoría, debido a que no te impiden avanzar, más bien, te invitan a avanzar en un cúmulo de escenarios retorcidos o enemigos hiper-pixelados.
En resumen: Un glitch es una consecuencia imprevista por el programador, que se auto corrige así misma en una especie de retroalimentación viciosa creando escenarios de lo más dantescos, mientras que un bug es un fallo del programador (no poder avanzar en X punto, morir de repente porque sí, no poder sacar X arma...)
Ejemplo de glitch: Missigno. Siempre quise tener un "borrón" en mi equipo.Pues bien, espero que lo hayáis captado, porque ahora viene lo divertido. Nuestro queridísimo Angry Video Game Nerd acaba de publicar su último episodio en el que precisamente habla de esto, glitchs en los juegos. Así que os invito a que le echéis un vistazo porque, pese a estar en inglés y quitando el detallito del goblin verde de los glitchs, que se hace bastante pesado, se muestran un par de ejemplos interesantes, en particular el mundo -1 del Super Mario Bros. del cual, yo, personalmente, no tenía ni zorra.
Disfrutadlo.
Disfrutadlo.
Microsoft .net vs Java
Posted by raul_id on jueves, 8 de julio de 2010
Muy buenos días de verano! Hoy mismo he visto uno de esos vídeos que no dejan indiferente. Se trata de una gran frikada hecha con un gusto exquisito. Un vídeo en forma de trailer que nos muestra la vida de una familia chapada a la .net, cuyo hijo empieza a descubrir nuevos mundos a escondidas con su archirrival Java. Es uno de los mejores vídeos freaks que he visto, llego no de pequeños detalles que lo hacen genial (efectos de sonidos sólo perceptibles por geeks, nombre de los personajes, ...). En definitiva, tenéis que verlo:
Y hasta aquí llegamos hoy. Nos leemos!
PD.: Esperamos que en otros post nos podamos extender algo más ;)
Aprende a usar la herramienta ADB para Android
Posted by raul_id on jueves, 1 de julio de 2010
También es cierto que siempre hay varios perfiles de usuarios de estos teléfonos. No me cabe la menor duda de que muchos de los usuarios de Android ni siquiera saben que su teléfono tiene este sistema operativo y son perfectamente felices con las funcionalidades por defecto; pero también sé que la gran mayoría quieren estar constantemente cacharreando.
Para estos últimos va dedicado este post de hoy. Porque cuando nos encontramos de primeras con un artilugio de estos y se nos ocurre ver la ingente cantidad de aplicaciones que hay en el Market nos podemos abrumar un poco. Pero todos sabemos que acabamos viendo tarde o temprano aplicaciones que descargamos de foros y otros medios... a nuestro ordenador y se hace un trabajo bastante farragoso ir pasando aplicaciones a nuestra SD para instalarlas desde el dispositivo.
Vamos a explicar un poco la herramienta ADB que nos ofrece el SDK (las herramientas para el desarrollo de aplicaciones) de Android. Además de la opción de instalar aplicaciones desde nuestro ordenador, nos brinda varias utilidades más que pueden resultarnos bastante útiles (acceso a la shell, enviar/recibir ficheros, ...).
Antes de nada me gustaría dejar claro que esto lo he probado en Ubuntu 10.04 con un Nexus One. Supongo que no será demasiado difícil extrapolar estos comandos a Windows para unos geeks como vosotros (pero bah! seguro que ninguno lo utiliza, xD).
Para poder utilizar esta herramienta deberemos tener previamente instalado el SDK de Android. En internet hay cientos de tutoriales, y no seré yo el que haga uno mejor. Tan solo decir que es muy importante utilizar las últimas versiones de los programas y no las que indican en los tutoriales ya que puede provocar conflictos entre ellos (java, eclipse, firmwares, ...).
Una vez conseguido esto (largo y arduo camino llevamos hasta aquí) ya tenemos todo lo necesario para usar nuestro querido ADB. Generalmente se recomienda que los archivos del SDK se hallan guardado en una carpeta localizable (en mi caso usuario/Desarrollo/android-sdk-linux_86) porque después tendremos que estar constantemente entrando a ella.
Los pasos a seguir para instalar una aplicación mediante ADB serán:
- Abrimos una terminal y entramos en la carpeta Tools que se encuentra dentro del SDK
- Ejecutamos los siguientes comandos: sudo ./adb kill-server sudo ./adb start-server sudo ./adb device
- Si después de este último comando nos aparece un código de números y letras es que vamos bien :) Si nos aparece una linea de asteriscos (*) es que algo hemos hecho mal.
- Metemos las aplicaciones que queramos instalar (los archivos .apk) dentro de la carpeta Tools.
- Desde el teléfono desactivamos el almacenamiento USB y vamos a Ajustes
- Ejecutamos el siguiente comando para cada aplicación: ./adb install -l nombreaplicacion.apk
Sin embargo, la herramienta ADB nos proporciona otros comandos a parte del "install" como pueden ser:
- ./adb reboot (Reinicia el terminal)
- ./adb push [archivo-pc] [origen-teléfono] (envía cualquier archivo desde el ordenador al terminal Android) Ejemplo: ./adb push laveneno.jpg /sdcard/fotosprivadas
- ./adb pull [archivo-teléfono] [origen-pc] (descarga a tu ordenador archivos que se encuentran en el teléfono) Ejemplo: ./adb pull /sdcard/fotosprivadas/laveneno.jpg laveneno.jpg
- ./adb shell (se nos abre una línea de comandos hacia el dispositivo, con todo lo que ello implica, sobretodo si tienes acceso root)
Inteligencia Artificial
Posted by Jose on lunes, 21 de junio de 2010
Recuerdo un día que, en una clase de una asignatura que cursé llamada Técnicas de Reconocimiento y Síntesis del Habla, íbamos a comenzar a dar materia sobre inteligencia artificial aplicada a sistemas que fueran capaces de reconocer tanto al locutor que hablaba como lo que propiamente decía. La cuestión es que, a modo de anécdota, el profesor nos contó que, cuando el cursó una asignatura sobre temática de inteligencia en computadores, se encontró con algo diferente a lo que las películas plantean. El tema es que a él, en esa asignatura, le mandaron realizar un sistema que, entrenado con los movimientos de la bolsa en los últimos años, fuera capaz de preveer los movimientos próximos (y así, de paso, forrarse). Entonces, un compañero mío le preguntó, muy ilusionado, si el sistema había llegado a funcionar, a lo que el profesor contestó que, de haber estado forrado, se habría pensado el madrugar esa mañana para venir a darnos clase.
La cuestión es que, por suerte o por desgracia, todavía estamos bastante lejos de conseguir tener un Skynet en nuestro ordenador y eso, en cierta manera, puede limitar nuestra experiencia para con los juegos, porque un título (excesivamente) previsible, puede implicar el desprecio del jugador en cuestión de poco tiempo.
Sin embargo, ¿cuándo podemos considerar un sistema inteligente? Allá por 1950 Alan Turing (científico d
e bastante reputación por, entre otras cosas, haber sido uno de los principales contribuyentes a "romper" el código de la máquina Enigma y, a pesar de ello, después no se puede decir que fuera tratado del todo bien por su país) planteó una especie de test, llamado el test de Turing, que de forma básica exponía que podríamos considerar el tener inteligencia artificial cuando, al interactuar un humano con esa "inteligencia", no fuera capaz de distinguir su naturaleza humana o artificial.
La cuestión es que, realmente esto, nunca (o casi nunca) se suele cumplir en un videojuego. En la gran mayoría de casos nos encontramos con acciones que vienen dadas por scripts que dicen qué ha de hacer el personaje de tipo NPC (Non Player Character) en cada caso, realizando siempre lo mismo (al fin y al cabo, son una serie de condicionales), o, en casos más elaborados, se utilizan algoritmos que permiten a los personajes "improvisar" un poco, como puede ser a la hora de buscar una ruta hacia un destino, tarea para la cual se suelen utilizar algoritmos de resolución de grafos para encontrar el camino óptimo (por ejemplo, el algoritmo de Dijsktra, muy utilizado en protocolos de enrutamiento en redes de ordenadores, es uno de los que se aplica en estos casos) o también las denominadas máquinas de estado finitas, muy utilizadas para la animación de sprites en videojuegos 2D, que permiten modelar una serie de estados (por ejemplo, desesperado, hambriento, andando...) por los que nuestro personaje puede, o no, pasar y que modificará, en parte, el comportamiento que tenga.
Pero volviendo al título del post, ¿cuándo encontramos realmente inteligencia artificial en un videojuego? Informándome por ahí, conseguí encontrar dos títulos (aunque hay más) que realmente implementan cierto aprendizaje automático (ya sea mediante redes neuronales o la técnica que sea), los cuales son:
Black and White: En este videojuego, consistente básicamente en ser un dios, debemos manejar una criatura que será nuestro "representante" en la Tierra. La criatura, desde que la obtenemos, irá aprendiendo en función de nuestras acciones (si castigamos mucho al pueblo o si somos benévolos) y, a la larga, se comportará en función a eso que haya ido aprendiendo.- Creatures: En este juego deberemos controlar a unas criaturas, llamadas norns, y deberemos intentar que sobrevivan en base a enseñarles qué es lo que han de hacer y qué no.
Pues nada, espero que os haya gustado el tema. Esperamos vuestros comentarios!!
Juegos en HTML 5
Posted by raul_id on jueves, 10 de junio de 2010
Pocos son, de momento, los aventurados en programar en HTML 5 ya que el Flash estaba muy asentado y supone aprender un lenguaje nuevo. Sin embargo, ya se están empezando a ver webs que anteriormente estaban en Flash, y con ello, la posibilidad de verlo en nuestros smartphones (por poner un ejemplo).
Pero el caso que nos ocupa, dada la temática de este, nuestro querido blog, es que también podemos ver iniciativas en las que se portan los clásicos minijuegos Flash de toda la vida a este nuevo lenguaje.
Una buena muestra de ello es la web de Akihabara donde encontraremos clásicos propios de la época de los 8 y 16 bits.
Por si el estilo plataformero de los juegos de la anterior página no es lo vuestro y sois como los redactores de este blog a quienes nos chiflan las aventuras gráficas, os interesa el siguiente enlace. Se trata de la web de SARIEN, propiedad de Martin Kool, quien ha desarrollado el motor gráfico de las antiguas aventuras de Sierra. En esta web podremos jugar al mítico Leisure Suit Larry de 1987!! en 16 colores!!! Ademas, podremos jugar a algunos más como:
- Gold Rush!
- King’s Quest: Quest for the Crown
- King’s Quest II: Romancing the Throne
- King’s Quest III: To Heir is Human
- Police Quest: In Pursuit of the Death Angel
- Space Quest I: The Sarien Encounter
- Space Quest II: Vohaul’s Revenge
- The Black Cauldron
SDL
Posted by Jose on domingo, 11 de abril de 2010
SDL son las siglas de Simple DirectMedia Layer, una serie de librerías escritas en el lenguaje de programación C y pensadas para el diseño de videojuegos, sobretodo 2D, por medio de la incorporación de rutinas de gestión de imágenes (cargar imágenes, desplazarlas por la pantalla, interacción entre varias...), sonido (cargar sonidos, reproducción de los mismos...), eventos (creación de una programación orientada a eventos, siendo capaz de detectar acciones sobre el teclado y ratón y realizando gestión de esos eventos realizando acciones a nuestra elección) y tiempo (también timers, para que el tiempo no dependa de la máquina a emplear).
SDL fue creado por Sam Lantinga de la empresa Loki Software (también Loki Entertainment Software) en aras de proporcionar una herramienta que fuera capaz de a
bstraer al programador/diseñador de videojuegos de las "tediosas" gestiones de bajo nivel de los dispositivos hardware (gestión de ratón, teclado, tarjeta de red, tarjeta de sonido) y de otras rutinas repetitivas y también de bajo nivel como la gestión de archivos (imágenes, audio...), y así permitir que éste se centrara más en la parte de desarrollo del videojuego que sobre la gestión de la propia máquina sobre la que trabajaba.
La consecuencia más clara de lo expuesto antes es que SDL permitía la portabilidad entre máquinas y sistemas operativos, es decir, al abstraer SDL la programación del juego de la arquitectura del sistema, siempre que nuestro sistema "entendiera" esta serie de librerías, podríamos "ejecutar" nuestro videojuego. Esto, en resumidas cuentas, significa que utilizando la programación estándar del lenguaje C (es decir, eliminando instrucciones del tipo llamadas al sistema) y con las librerías SDL, podemos desarrollar y ejectuar cualquier aplicación en una gran cantidad de plataformas: PC (con Windows, Linux...), MAC, consolas como PSP, Dreamcast y un largo etcétera.
Una de las aplicaciones más conocidas de esta herramienta es la máquina virtual ScummVM, herramienta que permite ejecutar cualquiera de las aventuras gráficas basadas en el motor gráfico Scumm (e incluso algunas que no utilizan ese motor), el cual fue creado por 
LucasArts y empleado en sus aventuras gráficas, permitiendo que, por ejemplo, podamos ejecutar el Maniac Mansion (videojuego que, para PC, fue publicado el año 1988) en un ordenador con un procesador con varios núcleos y más de algún gigahertzio de potencia.
Sin embargo, y como ocurre con todo, este sistema tiene sus pegas: mientras que para desarrollar una pequeña aplicación con este sistema se requieren ciertos conocimientos tanto de programación en gener
al como de las librerías SDL en particular, existen ciertos entornos de tipo WYSIWYG (siglas de What You See Is What You Get, filosofía de aplicaciones en las que, normalmente, se interactúa con un entorno gráfico y se crean aplicaciones por medio "golpes de ratón") en los que eso no es necesario y el desarrollo de una aplicación es mucho más rápido, sacrificando ciertas características como suele ser la portabilidad de aplicaciones o el mayor control de nuestra aplicación.
Por último, destacar que, aunque se ha hecho referencia todo el tiempo al lenguaje C, aunque estas librerías están realmente programadas en ese lenguaje, existen "migraciones" a otros lenguaje, como son Python, Pascal o Java (entre otros muchos), para aún así expandir más su ya de por sí gran alcance.
Suscribirse a:
Entradas (Atom)
Secciones
Blogs interesantes
Síguenos en Twitter!
