Obteniendo la colisión de videojuegos en PSX

Proyecto de Github aquí.

Recientemente me enfrenté al proyecto de reversing más complejo que he hecho hasta la fecha, pero antes de nada os pongo un poco en contexto:

Hace ya tiempo apareció en Youtube un canal llamado "GameHut", el cual trata sobre como se desarrollaban los videojuegos antiguamente, en especial en la epoca de la SEGA Saturn/Megadrive. El dueño del canal podría ser cualquier ex-programador de esa epoca... Pero no,  sorprendentemente se trata de Jon Burton, fundador y antiguo jefe de la compañía de videojuegos Travellers Tales.

Os animo a visitar su canal de Youtube ya que es muy interesante.

Curiosamente incluso llegó a ver mi video sobre la tech-demo de TT oculta que encontré, la cual según contestó en Twitter fue desarrollada por él mismo.

Bueno, la cuestion es que yo ya conocía algunos juegos de Travellers Tales, incluyendo los de PSX que estan basados sobre todo en peliculas de Pixar, y estando familiarizado con ellos, me dió la impresión de que compartian el mismo motor de alguna manera, y había algo que siempre había tenido curiosidad, y es... ¿Se puede obtener la colisión de estos juegos de alguna forma para hacerla visible?

Pues me llevó varios días de buscar estructuras de datos en la RAM del emulador relacionadas con la colisión, mucho ensamblador MIPS (Incluso llegué a mirar por encima el funcionamiento del coprocesador de la PSX) y bueno, aunque muchas veces mirar los datos de la RAM y cambiarlos arbitrariamente te da muchas pistas, el hecho de mirar lo que hacían las rutinas de ensamblador que accedían a esas direcciones me ayudó mucho.

Pues al final lo conseguí hacer, y efectivamente el motor de colisión es prácticamente el mismo en todos los juegos de TT, con algunos pequeños cambios entre alguno de ellos, por ejemplo: en TS2 y BLSC el motor es exactamente idéntico, y al contrario que en los juegos previos, los poligonos de colisión pueden ser o bien triangulos o bien cuadrilaterios (en los anteriores solo podían ser triangulos).

Travellers Tales Collision Viewer es una aplicacion Web (Javascript) que lee SaveStates del emulador PSXE y muestra los polígonos y objetos de colisión del nivel cargado en el momento de realizar el SaveState. Tiene soporte para todos los juegos de PSX desarrollados por Travellers Tales. Se muestra no solo la colisión del nivel final, sino también la de los polígonos de prueba que se usarían durante el desarrollo y testing del videojuego ¿A que me ha quedado bonico?

Polígonos de colisión de prueba de distintos tipos, situados fuera de los limites de uno de los niveles de TS2

El rincon oscuro de Technology-Hellín: Proyectos abandonados

No todos los proyectos que hago acaban haciéndose realidad, la primera vez que pasó fue hace ya 6 años cuando estaba aprendiendo a programar (que tiempos aquellos...) la causa principal fue falta de formación. ¡Casi parece un chiste hoy en día! Que joven que era entonces y que viejo que estoy ahora :P
A día de hoy los motivos por los que puedo cancelar un proyecto son o bien falta de tiempo (tengo mucho menos tiempo libre que antes) o simplemente que tras analizarlo, no encaja. Os dejo los 2 proyectos cancelados más relevantes actualmente:

JMusic
¿Recordais la APP para Android que hice para escuchar y descargar música que se encontraba en Youtube? Finalmente fue abandonada. ¿O eso creiais?

El logotipo del nuevo JMusic

JMusic necesitaba una actualización importante para darle impulso, y eso me hizo replantearla como... Una app de música en la nube privada. ¿Que quiero decir con eso? Sería una aplicación web accesible tanto en PC, IOS, Android,... habría una biblioteca de canciones, y radios online, organizadas por categorías, sincronizada siempre en todo momento en todos los dispositivos. Ademas tendría otras cosas molonas como un portapapeles, y una lista de enlaces compartida, todo sincronizado y almacenado en la nube. La falta de tiempo y los filtros de Instagram le hicieron mucho daño a la pobre:

• El desarrollo comenzó en Julio de 2019 una mañana de la semana que estuve de vacaciones en Benicassim (la playica). Ya tenía la idea pensada y estaba inspirado, asi que decidí empezar con el layout. Ya la continuaría durante mi tercera semana de vacaciones en Hellín
• El desarrollo continuó a la vuelta de mis segunda semana de vacaciones, en Asturias, concretamente desde el asiento trasero del coche (el viaje era largo y estaba aburrido) empecé a meterle JavaScript y mas cosicas. Al final de ese mismo día descubrí que me habían aceptado dentro de la beta de SparkAR para crear filtros de Instagram. Era una oportunidad muy importante para mi, para destacar y dar a conocer mis creaciones. JMusic podía esperar, y se quedó en el olvido.
• Navidades 2019-2020: habían pasado 6 meses, JMusic, mi proyecto en el cual seguía pensando muchas veces, seguía en un estado de desarrollo... Ya os podeis imaginar. Durante todas las vacaciones solo le dediqué 2 mañanas a continuarlo un poco.

¡Y ya esta! Es una APP privada (En principio la estoy haciendo para mi mismo, dudo que nadie quiera probarla) y por lo tanto siempre acabo dándole prioridad a cualquier otra cosa. Eso la esta condenando. Mi intención es que acabe saliendo a la luz algún día, aunque es mi proyecto que lleva más tiempo a mitad de desarrollo.

Flappy Adventure 3 (FA3)

No es un secreto que desde niño siempre quise crear mi propio videojuego 3D. Lo conseguí con FA2 en menos de una semana sin ninguna experiencia previa en diseño de videojuegos 3D. Un año después, tras ser portado a Realidad Virtual (VR), lo tenía claro: con más tiempo, y con la experiencia obtenida, podría hacer un videojuego muy decente, con montones de objetos dinamicos y su propio editor. Empecé con la tormenta de ideas para la 3ª entrega de la saga FA:

• Seguiría usando la librería Three.js pero esta vez crearía un Flappy Engine desde 0, en el que por una parte crease el modelo de SketchUp (Esta vez los objetos del modelo tendrían propiedades como distancia de dibujado,colisión, apariencia metalizada,..) y por otra parte los objetos dinámicos del nivel se cargarían aparte en un JSON que tambien contendría propiedades como el spawnpoint. Estos objetos tendrían su propio modelo SketchUp y su .js con su código propio, el cual aceptaría parámetros. Habrían muchos mas objetos dinámicos que en FA2, y algunos se crearía para un único nivel en concreto.
• Para añadir los objetos dinamicos en los niveles junto a sus propiedades (parámetros, como por ejemplo color, velocidad,...), así como para comprobar el rendimiento, número de poligonos, y la correcta visualización (Los objetos tendrían una distancia de dibujado para mejorar el rendimiento y FPS respecto a FA2, donde siempre estaban cargados todos los elementos del nivel) se dispondría de un editor, donde uno se pudiera mover libremente, insertar objetos, colocarlos, y modificar sus propiedades. Estos cambios se podrían comprobar inmediatamente llamando al HTML del juego con el JSON generado como parametro de la URL.
• En esta entrega se transportaría al jugador a una historia, igual que se hizo en la primera entrega de FA en la que flappy fue en busca de su pareja que finalmente resultó haber sido secuestrada por los Angry Birds. En este caso la historia sería mucho más profunda, con muchos niveles, dialogos,... Terminar cada nivel sería parecido a cuando terminas de ver el capitulo de una serie, que quieres ver como sigue. Se contempló la idea de poder manejar tanto a Flappy como a su pareja (rosa) con distintos poderes cada uno.
• La jugabilidad sería parecida a la de FA2, es decir, se dispondría de un numero limitado de saltos en el aire y habría que intentar no chocar contra las paredes. 
• Para FA3 habría pensado utilizar cel shading, que traducido al cristiano significa que la apariencia del videojuego sería como de dibujos animados. Este tipo de renderizado es poco frecuente, y habría llamado la atención. Se ha usado en juegos como Jet Set Radio.
• El juego habría sido en 3ª persona, puesto que haría mas fácil visualizar la posición de Flappy, y recibí muchos comentarios en FA2 de que "si estaba jugando al Minecraft" solo por el hecho de ser un juego en primera persona.

Lamentablemente, aun anotando todas estas ideas (y otras relacionadas con el código), cancelé el proyecto sin ni siquiera haberlo empezado a desarrollar. Los motivos fueron:

• Ya existen gran cantidad de juegos Indie con un gran nivel.  La recepción del juego muy probablemente sería nula. Sería hacer el juego para mi solo.
• El hecho de hacer un motor de 0, me llevaría mucho tiempo existiendo ya herramientas como Unity.
• Apenas tengo tiempo libre ahora con el trabajo, y por lo menos la mitad de ese tiempo prefiero pasarlo AFK.

Filtro de video mediana: CPU vs GPU

¡Feliz año nuevo chic@s!
Todo empezó cuando decidí crear un filtro de mediana para vídeo, el cual por ejemplo FFMPEG no incluye...
Pero empecemos por el principio... ¿En que consiste el filtro de mediana? Pues es un filtro de reducción de ruido para imagenes en el que para cada pixel, se busca junto a sus pixeles cercanos el que tenga el valor de la mediana.
En el caso de las imagenes en escala de grises es muy sencillo determinar este valor, pues solo tienen un canal con un brillo que pasa de 0 (negro absoluto) a 255 (blanco absoluto), pero en el caso de las imagenes a color, lo que hice fue sumar los valores r+g+b para obtener una luminancia aproximada sin hacer demasiados calculos, y es que uno de los problemas del filtro de mediana para imagenes es que es bastante lento.

Filtro de la mediana en acción: (Abrir imágenes para ver mejor)

Pues teniendo esto en cuenta, me puse a implementar mi código para calcular la mediana en imágenes RAW (RGB) en lenguaje C. Una vez que para cada pixel he obtenido el array con su valor y el de sus cercanos, para obtener la mediana hay que ordenarlos. Tras probar varios algoritmos de ordenación (no todos) el que mejor funcionó fue el insertion sort, y es que aunque suele ser malo ordenando arrays grandes, funciona bien cuando estos son pequeños (ej: en la mediana de 5x5 solo hay 25 elementos) y aunque tal vez no sea el mejor, era suficiente.

Pues tras compilar mi código con optimizaciones de compilador al máximo, y al ejecutarlo usando los 8 cores de mi Intel i5 de 8ª generación (8 hilos), los resultados con un video en HD (1280x720) de 300 frames fueron bastante lentos... La mediana de 3x3 no llegaba a 22 fps, y la de 5x5 que era la que más me interesaba no llegaba a 11fps. Esto en uno de los procesadores más actuales.

Pues iba a dejarlo así como estaba, cuando revisando las caracteristicas de mi portatil, recordé que contaba con una GPU NVIDIA MX130, que aunque es normalilla, nunca había llegado a programar sobre GPU y tenía curiosidad de si era capaz de ejecutar el mismo algoritmo y en cuanto tiempo.

Pues resulta que sí es posible ejecutar código en la GPU, para ello existen dos opciones: OpenCV (funciona para cualquier GPU de cualquier fabricante) y CUDA (solo para NVIDIA). Yo me decanté por CUDA en esta ocasión.

Pues me puse a aprender un poco sobre como se programaba en CUDA... y tras ejecutar el código equivalente en la GPU los resultados fueron los siguientes:

En esta ocasión la GPU no solo era capaz de ejecutar el mismo código, sino que además lo hacía más rápido. ¡Ya alcanzaba los 25 fps! y ademas usando la mediana de 5x5. Si comparamos la salida de ambos proyectos, vemos que es idéntica.

Si entramos en detalles tecnicos, la GPU es capaz de ejecutar hasta 2048 hilos simultaneos repartidos en distintos bloques. En mi implementación usé bloques de 8x8 hilos en los que cada hilo procesaba un único pixel. La imagen original la copio a la memoria global de la GPU (rápida) puesto que cada pixel iba a ser leido por más de 1 hilo, mientras que la imagen resultante era escrita directamente en memoria de la CPU (esto es denominado Zero Copy) puesto que aunque estos accesos son más lentos, esta memoria solo se accedía una vez por pixel para escribir el resultado y evitamos tener que copiar luego la memoria de la GPU a la CPU.

API de geolocalización de Google y sus peligros

Pongámonos en una de las siguientes situaciones:

• Eres un gran hacker: el p*** amo hackeando redes WI-FI y decides compartir capturas de pantalla/tutoriales de como usas Aircrack-ng o similares
• Estas usando una aplicación para analizar redes wifi cercanas ya sea en PC o smartphone (Ej: Acrylic WI-FI) y compartes capturas de pantalla de la aplicación
• Compartes las direcciones MAC de routers WI-FI cercanos de cualquier otra forma (Ej: te engañan mediante ingeniería social)

Suponemos que de alguna de estas formas compartimos las direcciones MAC de routers WI-FI cercanos y las hacemos publicas, no las tachamos ni ocultamos. ¿Que puede pasar?

Comprobamos lo fácil que es encontrar gente compartiendo esta información a través de la red social Instagram, donde comparten por ejemplo capturas de Airodump-ng.

Bueno, pues sin saberlo están compartiendo el lugar donde están/viven/hacen cosas malas. ¿como es posible?

Esto es gracias a la API de geolocalización de Google, la cual mediante las señales de los WI-FI y triangulación permite ubicarnos geográficamente a pesar de no tener GPS. ¿habeis probado alguna vez a pedirle a Google Maps vuestra ubicación desde PC? notaréis que os localiza con gran precisión.

Y es que solo hace falta saber unas pocas direcciones MAC de routers cercanos y Google ya es capaz de localizar la posición con un error de 10-50 metros. ¿Notáis el peligro?

Vamos a probarlo. Ejecutamos la siguiente petición con los datos de 3 direcciones MAC que hemos obtenido en un post de Instagram:

Y obtenemos la siguiente respuesta:

Si añadimos mas direcciones MAC aumentaremos la precisión, aunque con solo 3 ya tenemos un radio de error de tan solo 37 metros.

Ahora buscamos las coordenadas en Google Maps (o Bing Maps o donde querais) y voilà! localizado.

Os animo a jugar un poco con esto y a localizar a distintos jaquers ;)

(SIN IR CON MALAS INTENCIONES)

Mis filtros AR de Instagram

¡Es una realidad! Formo parte de la beta AR de Facebook, lo que me permite no solo desarrollar sino también publicar filtros AR para las historias de Facebook e Instagram.

Seguramente si sois usuarios de Instagram hayáis seguido alguna cuenta por el hecho de que al seguirla os aparecen nuevos filtros para las historias. Bueno, pues ahora yo también soy una de esas pocas personas, de hecho en España probablemente no seamos ni 50 (En realidad no tengo ni idea, aunque en los grupos solo participa gente extranjera).
Pero hay un problema: no tengo manera de promocionarme, y esta última semana apenas he ganado entre 10 y 20 nuevos seguidores y todos son guiris, así que aquí estamos de nuevo... Otro intento fallido de convertirme en influencer tras el fracaso de mi canal de Lloutuve, y el #UnfollowProjectFest (En realidad este último si que tuvo bastante exito).
En fin, en el primer vídeo podéis ver como son mis primeros filtros, y en el siguiente podéis ver un experimento AR cutre que hice en un par de horas en el que puedo controlar un coche RC virtual superdetallado diseñado en mi querido Google Sketchup (Sí, sigo usando la versión 8, la última que hizo Google).

Resumen:
Spiral: Genera una espiral en movimiento alrededor del cuerpo (varios colores para elegir, se puede cambiar el tamaño pellizcando la pantalla)
Puzzle: Convierte la imagen de la cámara en un puzzle de tamaño a elegir (3x3 - 4x5) que se mezclará y resolverá con movimientos aleatorios que serán cada vez distintos.
Frame: La imagen de la camara aparece en un pequeño rectangulo, circulo, o rombo con 3 colores a elegir (tocando la pantalla se cambian, pellizcando la pantalla se cambia el tamaño)
Malefica: Te convierte en la villana de moda de Disney
Lovely: Aparecen corazones detrás de ti y aplica un filtro rosado.
Mirrors: La imagen de la cámara aparece 4 veces haciendo zoom en zonas aleatorias de la pantalla
OldTV: Simula el efecto pixelado y curvo de los antiguos televisores CRT
Construction: Como el Minecraft pero en AR
Noise: Aplica ruido aleatorio a la imagen. (Se puede variar la intensidad)
Nebulosa: Combina la imagen de la cámara con la de distintas nebulosas que se pueden cambiar tocando la pantalla
Dithering: Aplica pixelado Dither a la imagen de la camara. Se puede cambiar el color y el tamaño de los pixeles pellizcando la pantalla LEDStarIG: La versión descafeinada de mi efecto LEDStar en Facebook en la que no se puede escribir texto personalizado. Versión de FB: https://www.facebook.com/fbcameraeffe...
Heather: Aplica distintos colores con la intensidad deseada sobre la imagen
CelShading: Aplica efecto posterizado a la imagen
Mosaic: La imagen de la camara aparece formada por pequeñas versiones coloreadas de la imagen de la cámara que cambian de tamaño al abrir la boca
Area51: Te convierte en un alien. Si en la cámara hay una segunda persona, la convierte en un alien aun más feo.
LeTRIX: letras verdes que caen que nada tienen que ver con una película conocida y por lo tanto no hay problemas de derechos de autor.
JustMe: Aplica distintos efectos al fondo detrás de ti: Blanco y negro, desenfoque, lineas horizontales, etc...
SpaceLander: 3 niveles de aterrizaje lunar. Girar la cabeza para girar la nave, y abrir la boca para propulsar
NotHuman: Aquí tampoco estoy mencionando ninguna peli de Holliwood. Como curiosidad que nadie ha notado, si cierras el ojo izquierdo se apaga la luz roja.
Fantasy: Efectos de color fantasiosos. Si tocas la pantalla se intensifican
LaserEyes: Cerrando los ojos se activa y desactiva el laser. Tocando la pantalla se cambia el color
TearDrops: Te hace llorar de lo cutre que es el filtro. Abriendo la boca se intensifican las lagrimas (una versión mejorada iba a ser subida pero los moderadores de Facebook no ven bien un filtro en el que sales llorando)
LoveShooter: Otro juego para pasar el rato. Comentad abajo hasta que puntuación habeis llegado. No me hago responsable si os partis el cuello por el nivel 74 (La velocidad sube cada vez más y no he puesto límite por lo que a partir de 50 ya es practicamente imposible). Ahh si, teneis que girar la cabeza para mover la mira y mantenerla 1 segundo en los corazones para hacerlos desaparecer
Thug-Life: Cierra los ojos y veras unas gafas pixeladas caer.

CTurtle: una buena forma de aprender C con la tortuga de LOGO

Ver CTurtle en mi GitHub
Es posible que algunos conozcáis el lenguaje de programación LOGO, puesto que se enseña/enseñó en algunas escuelas para empezar a aprender programación. Consiste en un lenguaje de programación donde básicamente mueves una tortuga con un lápiz en un entorno gráfico, con comandos como hacer avanzar la tortuga (fd) o hacer girar la tortuga (rt, lt). Esto esta muy bien, pero tiene un inconveniente: una vez dominas el lenguaje, no te va a servir para nada más aparte de mover la tortuga.
Aparte de esto, la mayoría de los interpretes de LOGO son antiguos, no tienen antialising en el dibujado, e incluso algunos ni siquiera son compatibles con los procesadores de 64 bit actuales.
Pues aprovechando estas vacaciones de navidad, he creado una librería para C muy fácil de utilizar que os permitirá hacer dibujicos de la misma manera que se hace en LOGO en el lenguaje de programación C.
Esta librería consta únicamente de 2 archivos turtle.c y turtle.h aparte de la librería SDL, y tiene una implementación propia de antialising (En la cual dediqué gran parte del tiempo) y es compatible con Windows, Linux (Incluyendo Raspberry Pi), e imagino que en Mac también.

Ej:

El programa de la imagen sería el siguiente:

	#include <stdio.h>
	#include "turtle.h"
	void fern(int size, int sign);
	void fern(int size, int sign)
	{
	if (size<1) return;
	t_penSize(size/4);
	t_forward(size);
	t_turnRight(70*sign);
	fern(size/2,sign*-1);
	t_penSize(size/4);
	t_turnLeft(70*sign);
	t_forward(size);
	t_turnLeft(70*sign);
	fern(size/2,sign);
	t_penSize(size/4);
	t_turnRight(77*sign);
	fern(size-1,sign);
	t_turnRight(173*sign);
	t_penUp();
	t_forward(size*2);
	t_penDown();
	t_turnLeft(180);
	}
	int main(int argc, char ** argv)
	{
	if (t_init(640,480,window)!=0) puts("Init error");
	else {
	t_autoframeOff();
	t_moveSpeed(200);
	t_turnSpeed(0);
	t_penUp();
	t_goTo(192,450);
	t_setAngle(0);
	t_penDown();
	t_turColor(0,60,0);
	fern(25,1);
	t_frame();
	t_saveBMP("fern.bmp");
	t_idle();
	}
	}

Aparte de las instrucciones básicas como t_forward y t_turnRight también tenemos otras instrucciones opcionales como t_autoframeOff, t_moveSpeed y t_turnSpeed relacionadas con la animación, y otras instrucciones de utilidad interesantes como t_saveBMP que guarda en un archivo BMP el contenido de la pantalla.
La librería esta totalmente documentada en cualquier caso. Si aun así tenéis dudas o sugerencias, me las podéis comentar por aquí.

Hackeando un drone y leyendo una EEPROM con transistores y leds

¡Feliz año nuevo lectores inexistentes!
En esta ocasión os traigo 2 3 experimentos de electrónica divertidísimos (okno).
En el primer experimento desarmamos un drone FPV y nos encontramos con que tiene dos placas. Una para el FPV (el wifi y la camara) y otra para el control y todo lo demas (el drone podría funcionar unicamente con esta última placa). Estas placas se comunican a traves de un puerto serie UART a 19200 baudios. Tras conectar este puerto seríe a mi Arduino, me pongo a analizar que datos se envian desde la placa FPV a la principal. Y este es el resultado:

En el segundo experimento os muestro como se puede leer y escribir de una EEPROM (Un chip de memoria no volatil, como los pendrais) con el protocolo I2C sin ordenador, Arduino, ni nada,... de forma manual con solo unos cuantos transistores y resistencias.

Y por último, por si os habíais quedado con ganas de mas cacharreos, os muestro como se puede transmitir una señal de audio a través de un emisor y receptor de infrarrojos.

¿Dudas? ¿Sugerencias? Que bien, ¡habéis entendido todo! :')

Technology-Hellín ahora en GitHub

Desde el inicio de mi blog, (Cuando pasó de ser un blog personal a centrarse en la tecnología) siempre que he tenido la necesidad de subir algún contenido, ROM, o código fuente he recurrido a Google Drive. Pero hoy día, con el grado en ingeniería informática ya terminado y años de experiencia realizando proyectos (No solo en mi blog) ya iba siendo hora de recurrir a una plataforma mas profesional.

https://github.com/juanmv94

Aparte de algunos proyectos que ya tenía en el blog, he creado algunas 'cosicas' nuevas que os pueden gustar:

-JVideo (Extensión Google Chrome): Permite ver sin anuncios y descargar vídeos y pelis de internet.

-Librería Jsocket (C++): Una librería que permite crear conexiones e implementar servidores con sockets TCP. La principal diferencia respecto a otras librerías es que es muy muy fácil de usar y el mismo código fuente os sirve para Windows y Linux.

-Librería JJSON (Java, C++): Una librería para manejar y generar cadenas JSON.

-SOCKS2HTTP (C++): Genera un proxy HTTP a partir de un proxy SOCKS5 como puede ser Tor. Es el resultado de haber perdido el código fuente en Java de mi anterior proyecto.

Si tenéis tiempo echadles un vistazo y me comentáis ;)

Motor 3D para GameBoy Advance: Consiguiendo lo imposible

Versión 2:
Descarga ROM y código fuente aquí.
Esta versión ya se mueve fluida a 60fps y permite girar la cámara.
Cambios:
Aparte de las optimizaciones de la versión 1, he añadido mas optimizaciones, y he implementado la rotación de la camara.
-Todo el código es copiado a la RAM y se ejecuta desde ahí. Se usa código ARM en vez de Thumb.
-Para ganar mas velocidad utilizo el modo5, que baja un poco la resolución y permite tener dos framebuffer en la memoria de video evitando tener que usar la RAM para luego copiarla a la VRAM en cada frame. También uso las técnicas de escalado y desplazamiento de la GBA para crear un par de frames intermedios mientras se renderiza el siguiente frame final.

Para la rotación utilizo aproximaciones rápidas de lo que serían los auténticos cálculos de la rotación. Ademas, cada vez que se gira, desplazo la posición de referencia para evitar aun mas cálculos al transformar las coordenadas durante el dibujado.

Para evitar aun mas perdidas de velocidad, he replicado la función crítica Render para cada angulo posible, de forma que las transformaciones de coordenadas están hard-coodeadas dentro de las funciónes Render-n, evitando llamadas a funciones y comprobaciones de angulo cada vez que se procesa un pixel.

Versión 1:
Descarga ROM y código fuente aquí.
La GameBoy Advance fue una de las primeras videoconsolas portatiles que intentó en algunos de sus juegos simular el efecto 3D. Juegos como Driv3r, Asterix y Obelix XXL, o Craxy Taxi. No obstante en la mayoría de dichos juegos el efecto 3D era muy, muy básico. Es por eso que yo, como friki ingeniero informático que soy me puse a investigar de que manera se podría conseguir un motor 3D decente. Tras un día investigando y picando código...¡Este fue el resultado!

Como habréis comprobado, la calidad del efecto 3D casi no se puede comparar con la de ningún otro juego de GBA. El motor es de tipo voxel space y el video fue acelerado algo así como x200 ya que la demo en su versión original (la del vídeo) tardaba 11 segundos en generar cada frame. Esto es debido a la gran cantidad de multiplicaciones y divisiones que debía hacer el motor en cada frame. Para los que no sepáis muy bien como funciona un motor voxel space os lo explico de manera muy sencilla:

Tenemos una imagen de color y otra imagen de profundidad. Dibujamos el entorno desde el frente hacia atras aplicando perspectiva (podeis ver el triangulito con el campo de visión en el GIF), para ello trazamos en la pantalla lineas verticales del color proporcional al pixel horizontal de la pantalla y el pixel horizontal de la linea de campo de visión actual. Esta linea vertical empezará desde la ultima altura dibujada hasta un nuevo valor calculado a partir de la altura en el mapa de profundidad y la distancia con el punto de vista (Si el valor obtenido es menor, no se dibuja la linea).

Optimizando el código:

Pues seguramente la baja potencia del procesador de la GameBoy fue lo que hizo que no apareciera ningún juego usando este tipo de motor, las multiplicaciones y divisiones son muy lentas en su procesador. Estas operaciones son vitales tanto para calcular las posiciones horizontales del campo de vision y pantalla como las de las alturas. ¿Que solucion tenemos? ¡Crear una estructura de datos con estos valores precalculados! En el archivo comprimido podeis encontrar generarmatriz.c que puede ser compilado para PC y usando los datos de matrizalturas.h (compartido con el proyecto devkit) generar una estructura de datos con las alturas precalculadas matrizalturas.raw y posiciones horizontales matrizx.raw las cuales se añaden al ROM. También, para realizar otras divisiones y multiplicaciones con multiplos de 2, utilizo a ser posible las operaciones de desplazamiento << y >> las cuales son mas rápidas.

Ademas, calcularemos el campo de visión menos frecuentemente en posiciones alejadas y limitamos la distancia de dibujado a 512 pixeles.

Estos cambios, junto con otras cuantas optimizaciones de código, permiten tras un gran esfuerzo y sudor conseguir unos gloriosos...

¡5fps!

Lo cual supone aproximadamente un speedup del 3000% y seguiría siendo insuficiente para cualquier juego en condiciones, pero al menos se mueve decentemente.

Se podría decir que la optimización es del 95% ya que los limites técnicos de la consola están ahí. Estas son algunas otras optimizaciones menores posibles que ni me he molestado en hacer:

• Alinear matrizx.raw a 256 bytes cada linea para asi a la hora de leer sus datos podamos cambiar SCREEN_WIDTH*(step-minstep) por (step-minstep)<<8 aunque esto nos hará desperdiciar 16 bytes de memoria en la estructura de datos en la ROM por cada linea.
• Dibujar las lineas verticales una por una, de forma que si una alcanza el valor maximo se haga un break y se pase a la siguiente sin seguir avanzando en profundidad. Solo habría aceleración en los casos que el mapa alcanzase la parte de arriba de la pantalla y la aceleración sería irregular. Habría que almacenar los valores de step en una estructura de datos.
• Si se os ocurriese alguna mas, ¡comentad!

Curiosidad:

Uso de memoria en la demo:

Elemento	Espacio (KB)	Porcentaje	Notas
Código	9.79	0.18%	El corasón de la demo. La parte que controla todo el funcionamiento.
Imagen Background	39.1	0.72%	La imagen del cielo tan bonica para la mitad superior de la pantalla (240x80) a 16 bit bgr555
Mapa colores	2048	38.07%	1024x1024 a 16 bit bgr555
Mapa profundidad	1024	19.03%	1024x1024 a 8 bit (valores 0-255)
Matriz x	238	4.42%	Valores para cada pixel horizontal (1-240) en cada profundidad (8-512) de la posición horizontal del campo de visión (valores de 16 bit)
Matriz Alturas	2021	37.57%	Valores de altura en la pantalla de 8 bit para cada altura del mapa (0-255) en cada profundidad (8-512) para distintas alturas de camara posibles (16)
Total	5379.89	100%

Frikada del día: SOCKS5->HTTP, navega por la deep web desde IOS/Edge/IE

¿Quien no ha querido nunca navegar por la deep web desde su navegador favorito Internet Explorer?
Tanto IOS, como Edge, como el obsoleto Internet Explorer tienen un problema con los proxys en común, y es que no traen soporte para el protocolo SOCKS5 que es el tipo de proxy que utiliza tor.

Ahora es posible hacerlo gracias a un programa en Java creado por mi, que en unas 160 lineas de código, se conecta a un proxy SOCKS5 (como puede ser tor) y devuelve un proxy HTTP al que nos podemos conectar desde los navegadores de Microsoft o nuestros dispositivos de Apple.

Problema con IOS: Por alguna razon en las ultimas versiones de IOS, cuando intentas acceder a un sitio .onion, en Safari, te muestra un mensaje de que no tienes conexión a internet y el navegador ni se molesta en conectarse a traves del proxy. Se puede navegar anonimamente por el resto de paginas en cualquier caso.
Este problema no ocurre en cambio con mi antiguo Iphone 4 con IOS7.

Actualización:
Tras perder el código fuente original en Java, el cual aun tenía algunos fallos por resolver, he re-escrito el programa en C++ (Más eficiente) con mi librería Jsocket. Podeis encontrar el código fuente y ejecutable para Windows en https://github.com/juanmv94/SOCKS2HTTP.