FFMPEG: Creando un motor 3D???

Si os gustó mi último post sobre FFMPEG, este os hará replantearos mi nivel de salud mental. En esta ocasión trataré de implementar el motor Voxel Space que ya usé en mi demo de GameBoy Advance y en lenguaje LOGO, mediante filtros de video de FFMPEG, esto es sin ninguna línea de código.

Pues bien, la forma en la que funciona este motor voxel esta perfectamente documentada en este repositorio de GitHub: https://github.com/s-macke/voxelspace

Básicamente, y dicho de una forma que se entienda sin formulas ni código, debemos:

1. Aplicar perspectiva en el eje X de forma que cuanto más cerca este un elemento del mapa de la cámara, más "zoom" haremos
2. De la misma forma en el eje Y, cuanto más cerca este un elemento del mapa de la cámara, más se exagerará la elevación
3. Trazar lineas verticales que alcancen esa altura calculada, empezando o dando prioridad a las más cercanas a la cámara

Bueno. ¡Empecemos! Usaremos el mismo mapa de siempre, dos archivos c.png y p.png

Lo primero que haremos en FFMPEG es unir el mapa de color y alturas (el cual pasará a ser el canal alpha) para poder trabajar con ellos de forma conjunta. Esto lo haremos con el filtro: alphamerge

A continuación recortaremos el mapa a un tamaño que sea el que tendrá nuestra salida de video. Esto lo haremos con el filtro: crop=340:256:9

Muy bien, ahora si queremos animarlo para que por ejemplo de vueltas, tendremos que añadir rotación antes de hacer el crop, y de paso añadiremos un poco de desplazamiento hacia los lados con: rotate=n/50:bilinear=0,crop=340:256:64+32*cos(n/25)

Aquí "n" es el número de frame, y usamos la opción bilinear=0 para que busque siempre el pixel más cercano en vez de calcular promedios, que afectarían al mapa de alturas.

Muy bien, ahora ¡empecemos a implementar nuestro motor! para aplicar perspectiva al eje X usaremos el filtro qeg que permite aplicar una formula a cada valor de pixel, en este caso para los colores la formula será p(floor(170+(X-170)*Y/256),Y)

Sobra decir que aquí 170 es la mitad del ancho y 256 es el alto. ¡De momento pinta bien! Para el canal alpha donde también hay que "exagerar" las alturas la formula será clip((height-alpha(floor(170+(X-170)*Y/256),Y))/Y*scale_h+horizon,0,255)
usamos clip para mantener los valores dentro de nuestro rango de altura 0-255.

Ahora, para trazar las lineas verticales en principio es necesario un bucle FOR iterando las distintas profundidades como se puede ver en el primer GIF. Esto en FFMPEG no es tan sencillo, aunque en principio existe una función "while" en la expresiones de filtros, me decantaré por usar varios IF-ELSEs encadenados para reducir la complejidad al máximo, aunque como resultado me quede un comando demasiado largo. Empecemos a partir de la profundidad 5 hasta el final en 255. Sería algo así:

if(gt(Y,alpha(X,5)),p(X,5), if(gt(Y,alpha(X,6)),p(X,6), if(gt(Y,alpha(X,7)),p(X,7), if(gt(Y,alpha(X,8)),p(X,8), if(gt(Y,alpha(X,9)),p(X,9), if(gt(Y,alpha(X,10)),p(X,10),

...

Y este sería el resultado final: ¡Funcionó!

El resultado animado que nos devuelve FFMPEG sería el siguiente:

ffmpeg -loop 1 -i c.png -loop 1 -i p.png -filter_complex "[0][1]alphamerge,rotate=n/50:bilinear=0,crop=340:256:64+32*cos(n/25),geq='p(floor(170+(X-170)*Y/256),Y)':a='clip((120-alpha(floor(170+(X-170)*Y/256),Y))/Y*280+0,0,255)',geq=' if(gt(Y,alpha(X,5)),p(X,5), if(gt(Y,alpha(X,6)),p(X,6), if(gt(Y,alpha(X,7)),p(X,7), if(gt(Y,alpha(X,8)),p(X,8), if(gt(Y,alpha(X,9)),p(X,9), if(gt(Y,alpha(X,10)),p(X,10), if(gt(Y,alpha(X,11)),p(X,11), if(gt(Y,alpha(X,12)),p(X,12), if(gt(Y,alpha(X,13)),p(X,13), if(gt(Y,alpha(X,15)),p(X,15), if(gt(Y,alpha(X,16)),p(X,16), if(gt(Y,alpha(X,17)),p(X,17), if(gt(Y,alpha(X,19)),p(X,19), if(gt(Y,alpha(X,20)),p(X,20), if(gt(Y,alpha(X,22)),p(X,22), if(gt(Y,alpha(X,23)),p(X,23), if(gt(Y,alpha(X,25)),p(X,25), if(gt(Y,alpha(X,26)),p(X,26), if(gt(Y,alpha(X,28)),p(X,28), if(gt(Y,alpha(X,29)),p(X,29), if(gt(Y,alpha(X,31)),p(X,31), if(gt(Y,alpha(X,33)),p(X,33), if(gt(Y,alpha(X,34)),p(X,34), if(gt(Y,alpha(X,36)),p(X,36), if(gt(Y,alpha(X,38)),p(X,38), if(gt(Y,alpha(X,40)),p(X,40), if(gt(Y,alpha(X,41)),p(X,41), if(gt(Y,alpha(X,43)),p(X,43), if(gt(Y,alpha(X,45)),p(X,45), if(gt(Y,alpha(X,47)),p(X,47), if(gt(Y,alpha(X,49)),p(X,49), if(gt(Y,alpha(X,51)),p(X,51), if(gt(Y,alpha(X,53)),p(X,53), if(gt(Y,alpha(X,55)),p(X,55), if(gt(Y,alpha(X,57)),p(X,57), if(gt(Y,alpha(X,59)),p(X,59), if(gt(Y,alpha(X,62)),p(X,62), if(gt(Y,alpha(X,64)),p(X,64), if(gt(Y,alpha(X,66)),p(X,66), if(gt(Y,alpha(X,68)),p(X,68), if(gt(Y,alpha(X,71)),p(X,71), if(gt(Y,alpha(X,73)),p(X,73), if(gt(Y,alpha(X,75)),p(X,75), if(gt(Y,alpha(X,78)),p(X,78), if(gt(Y,alpha(X,80)),p(X,80), if(gt(Y,alpha(X,83)),p(X,83), if(gt(Y,alpha(X,85)),p(X,85), if(gt(Y,alpha(X,88)),p(X,88), if(gt(Y,alpha(X,90)),p(X,90), if(gt(Y,alpha(X,93)),p(X,93), if(gt(Y,alpha(X,96)),p(X,96), if(gt(Y,alpha(X,98)),p(X,98), if(gt(Y,alpha(X,101)),p(X,101), if(gt(Y,alpha(X,104)),p(X,104), if(gt(Y,alpha(X,106)),p(X,106), if(gt(Y,alpha(X,109)),p(X,109), if(gt(Y,alpha(X,112)),p(X,112), if(gt(Y,alpha(X,115)),p(X,115), if(gt(Y,alpha(X,118)),p(X,118), if(gt(Y,alpha(X,121)),p(X,121), if(gt(Y,alpha(X,124)),p(X,124), if(gt(Y,alpha(X,127)),p(X,127), if(gt(Y,alpha(X,130)),p(X,130), if(gt(Y,alpha(X,133)),p(X,133), if(gt(Y,alpha(X,136)),p(X,136), if(gt(Y,alpha(X,139)),p(X,139), if(gt(Y,alpha(X,142)),p(X,142), if(gt(Y,alpha(X,146)),p(X,146), if(gt(Y,alpha(X,149)),p(X,149), if(gt(Y,alpha(X,152)),p(X,152), if(gt(Y,alpha(X,155)),p(X,155), if(gt(Y,alpha(X,159)),p(X,159), if(gt(Y,alpha(X,162)),p(X,162), if(gt(Y,alpha(X,166)),p(X,166), if(gt(Y,alpha(X,169)),p(X,169), if(gt(Y,alpha(X,172)),p(X,172), if(gt(Y,alpha(X,176)),p(X,176), if(gt(Y,alpha(X,180)),p(X,180), if(gt(Y,alpha(X,183)),p(X,183), if(gt(Y,alpha(X,187)),p(X,187), if(gt(Y,alpha(X,190)),p(X,190), if(gt(Y,alpha(X,194)),p(X,194), if(gt(Y,alpha(X,198)),p(X,198), if(gt(Y,alpha(X,202)),p(X,202), if(gt(Y,alpha(X,205)),p(X,205), if(gt(Y,alpha(X,209)),p(X,209), if(gt(Y,alpha(X,213)),p(X,213), if(gt(Y,alpha(X,217)),p(X,217), if(gt(Y,alpha(X,221)),p(X,221), if(gt(Y,alpha(X,225)),p(X,225), if(gt(Y,alpha(X,229)),p(X,229), if(gt(Y,alpha(X,233)),p(X,233), if(gt(Y,alpha(X,237)),p(X,237), if(gt(Y,alpha(X,241)),p(X,241), if(gt(Y,alpha(X,245)),p(X,245), if(gt(Y,alpha(X,249)),p(X,249), if(gt(Y,alpha(X,253)),p(X,253),145)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))':a=255" -r 25 -qp 0 salida.mp4

¿Preguntas? ¿Dudas?

FFMPEG: Añadiendo pulsaciones del mando a tus gameplays en emulador

Algunos emuladores permiten grabar tus gameplays/speedruns de forma que las pulsaciones del mando se graban y luego se puede volver a reproducir ese mismo gameplay, pudiendo incluso exportar el gameplay a video.

Pues hay gente a la que le gusta ver las pulsaciones del mando a la vez que mira el gameplay, y no hay muchas herramientas para ello. Aquí os enseñare como se puede hacer tal cosa tan solo usando el codificador de video FFMPEG, nada de programas externos. Así es, solamente FFMPEG y sus filtros. Para este ejemplo usaré el emulador de NES Nestopia.

Este emulador en concreto guarda las grabaciones (comprimidas con ZLIB) en bloques de 8 bytes por frame donde cada byte representa uno de los 8 botones del mando de la NES. 0x40 cuando no esta pulsado, 0x41 cuando esta pulsado.

Muy bien, ¿y que hacemos con este archivo en FFMPEG? Pues resulta que podemos abrirlo como rawvideo. Le decimos a FFMPEG que tiene una resolucion de 8x1, que esta en escala de grises (1 byte por pixel), y le adaptamos el brillo y contraste para que se note la diferencia de 0x40 y 0x41.

Ahora si ponemos el video .AVI exportado y el rawvideo del mando uno encima del otro, nos quedaría algo así:

ffmpeg -f rawvideo -pixel_format gray -video_size 8x1 -framerate 60 -i input.dat -i v.avi -filter_complex [0]eq=brightness=1:contrast=6.1:gamma=10,scale=256:-1:flags=neighbor[k];[1][k]vstack v.mp4

¡Nada mal de momento! La sincronización de las pulsaciones en los pixeles de abajo es perfecta, pero ahora nos faltaria visualizarlo como un mando de NES. Para ello lo primero es dibujarnos nuestro mando de NES:

Ahora lo que haremos mediante el filtro geq es mapear las posiciones de los pixeles para que iluminen los botones correspondientes del mando que hemos dibujado. No hace falta complicarnos mucho con la forma exacta de los botones, luego haremos que iluminen solo las zonas grises con blend.

Ahora el resultado es el siguiente:

ffmpeg -f rawvideo -pixel_format gray -video_size 8x1 -framerate 60 -i input.dat -i controller.png -i v.avi -filter_complex [0]scale=256:128:flags=neighbor,eq=brightness=1:contrast=6.1:gamma=10,geq=g='if(gt(X,193),p(0,0),if(gt(X,163),p(32,0),if(gt(X,120),p(96,0),if(gt(X,90),p(64,0),if(gt(X,62),p(224,0),if(gt(X,48),if(gt(Y,77),p(160,0),if(lt(Y,64),p(128,0))),p(192,0)))))))':r=0:b=0[k];[k][1]blend=all_mode=hardlight[p];[2][p]vstack v.mp4

También podemos hacer que el mando aparezca sobre la imagen, e incluso que tenga un componente alpha. El resultado sería el siguiente:

ffmpeg -f rawvideo -pixel_format gray -video_size 8x1 -framerate 60 -i input.dat -loop 1 -i controller.png -i v.avi -filter_complex [0]scale=256:128:flags=neighbor,eq=brightness=1:contrast=6.1:gamma=10,geq=g='if(gt(X,193),p(0,0),if(gt(X,163),p(32,0),if(gt(X,120),p(96,0),if(gt(X,90),p(64,0),if(gt(X,62),p(224,0),if(gt(X,48),if(gt(Y,77),p(160,0),if(lt(Y,64),p(128,0))),p(192,0)))))))':r=0:b=0[k];[k][1]blend=all_mode=hardlight[p];[1]alphaextract[a];[p][a]alphamerge,scale=128:-1:flags=neighbor[pa];[2][pa]overlay=main_w-overlay_w:main_h-overlay_h:shortest=1 v.mp4

¿Que os ha parecido? ¿Que otras ideas teneis para implementar en FFMPEG?

Head On / Crash: Predecir los movimientos de la CPU

 Si eres viejo, como yo, es posible que recuerdes el juego Arcade "Head On" (Gremlin) o "Crash" (Exidy) de 1979. Básicamente los dos son una copia el uno del otro. Es un juego simple y adictivo, y que sirvió de inspiración para Pac-Man unos años más adelante, es el primero de la historia con el objetivo de recoger todos los "puntitos". En él llevas un cochecito que va en sentido anti-horario en un circuito de 4 carriles, mientras que otro cochecito va en dirección contraria en sentido horario intentando chocarse contigo, y si lo consigue: GAME OVER

Aquí en este video podeis ver el gameplay de la versión GameBoy, que es la que voy a desensamblar en esta ocasión.

Y pensareis... Pues el cochecito de la CPU intentará moverse siempre al mismo carril donde estemos nosotros para chocar. ¡Que fácil! ... Pues no. El cochecito de la CPU a veces hará cosas raras como moverse 2 carriles cuando solo estamos a 1 de distancia. ¡Incluso se puede dejar el juego en bucle infinito sin que choque nunca!

Más raro aun, en algunas ocasiones incluso se puede ver al cochecito de la CPU sin cambiar de carril pasando totalmente de nosotros. WTF?

Pues bien, llegó la hora de desensamblar, y por suerte el algoritmo que dicta al cochecito si debe girar o no esta contenida en una única función en 0x3efc que se llama cada frame

Si reemplazamos la llamada por NOPs, el cochecito de la CPU no girará nunca

Os voy a ahorrar leer ensamblador, así que os pondré las direcciones de memoria con las variables del juego que nos importan, y a continuación una traducción a lenguaje C:

0xC024 -> CPU_Y (Posicion Y del cochecito de la CPU)
0xC025 -> CPU_X (Posicion X del cochecito de la CPU)
0xC132 -> dir (Dirección del cochecito de la CPU 0-3. 0=IZQUIERDA,...)
0xC127 -> frame_giro (contador de frames que llevamos sin girar el cochecito de la CPU)
0xC138 -> velocidad (velocidad del cochecito. Incrementa al recolectar puntitos)
0xC13A -> flag_mov (¡este es importante! su valor {0x10, 0x20, 0x40, 0x80} cambia cada vez que los cochecitos del jugador, o de la CPU salen de una intersección entrando en los carriles, y cuando el cochecito de la CPU cambia de dirección "dir". Indica hacia donde debe moverse el cochecito de la CPU para girar y acercarse al cochecito del jugador. Si están en el mismo carril, valdrá 0x00)

if (velocidad==1) {
  frame_giro++;
  if (frame_giro!=4) return;
  frame_giro=0;
} else {
  frame_giro++;
  if (frame_giro!=2) return;
  frame_giro=0;
}

switch (dir) {
  case IZQUIERDA:
    if (CPU_X<0x48 || CPU_X>0x60) return;
    if (flagmov & 0x40) {
      CPU_Y=max(CPU_Y-1, 0X6F);
    } else if (flagmov & 0x80) {
      CPU_Y=min(CPU_Y+1, 0X93);
    }
    return;
......................................

Como veis el código es muy muy simple. Se divide en 2 bloques: el primero limita el giro a cada 2/4 frames dependiendo de la velocidad que tenga el cochecito de la CPU, y el segundo simplemente lo mueve en la dirección indicada por flagmov cuando se encuentre en una intersección sin salirnos de los limites. Realmente nunca controla si quiere moverse 1 o 2 carriles. Entonces... ¿que pasa? Centremonos en el primer bloque:

• En velocidad 1 se desplaza lateralmente cada 4 frames, y así le da tiempo a desplazarse 2 carriles, aunque el jugador este solo a 1 de distancia.
• En velocidad 2 se desplaza lateralmente cada 2 frames, y así también le da tiempo a desplazarse 2 carriles, aunque el jugador este solo a 1 de distancia.
• En velocidad 3 y en adelante, se desplaza lateralmente cada 2 frames y solo le da tiempo a desplazarse 1 carril, aunque el jugador este a 2 o más de distancia.

Resumiendo, el coche de la CPU saltará siempre o 1 o 2 carriles dependiendo únicamente de la velocidad que tenga, moviendose siempre en dirección hacia el carril del jugador (esta dirección cambia cuando los coches salen de las intersecciones y entran de nuevo en los carriles)

Pero entonces... ¿Que ocurria cuando el cochecito de la CPU no cambiaba de carril y nos ignoraba?

Si veis el GIF detenidamente, veréis que justo antes de entrar al cruce, cambiaba de velocidad (1 -> 2)

⚠ ¡Alerta, bug! ⚠ si el valor de 0xC127 -> frame_giro en ese momento de cambiar velocidad vale 2 o 3, se seguirá incrementando sin control sin que llegue a valer de nuevo 2, y por lo tanto sin ejecutar ninguna lógica de giro durante los siguientes 254 frames, que es cuando el numero de 8bit hará overflow.

¿Que os ha parecido? Ahora que sabéis la lógica sigue el cochecito de la CPU, ya nunca veréis el juego de la misma forma. ¿preguntas? ¿dudas?...

Flappy Adventure 3 - Nuevo juego para PS1

 Descarga ISO Aquí

Era un secreto a voces: Flappy Adventure 3, la entrega que pondría fin a la saga "Flappy Adventure" estaba en desarrollo, no para version web como planeaba originalmente, sino para PS1 igual que su predecesor Flappy Adventure X, al ser una plataforma para la cual apenas hay homebrew en la actualidad.

De hecho fue a finales de Octubre de 2024 cuando me puse a experimentar en la creación de un motor 3D decente para PS1, puesto que no existía ninguno de software libre y esto frenaba mucho la creación de homebrew para PS1 (El de Flappy Adventure X era muy simple).

Fue poco después en Noviembre, cuando viendo que el motor funcionaba e iba bien, decidí empezar la idea de crear una pequeña demo de como podría verse mi proyecto abandonado de "Flappy Adventure 3" en la PS1 con ese motor. Sería en 3ª persona, tal y como siempre había planeado, no sería "cel shading" pero si tendría una apariencia con colores vivos y poquitas texturas dándole un aspecto caricaturesco.

¡Y así empezó todo! Aunque el proyecto fue abandonado en varias ocasiones por pura dejadez, estando parado casi un año entero, finalmente "Flappy Adventure 3" vio la luz, con muchos recortes frente a la idea original, eso sí, puesto que el desarrollo se estaba alargando mucho para las no más de 10 personas que planeo podrían llegar a probar el juego.

⚫ La pantalla original de selección de niveles iba a ser el nivel 0 del juego basado en Minecraft, con portales que tele-transportarían al resto de niveles como en Flappy Adventure X, aunque descarté la idea por ser muy repetitiva (ya se hizo en FADVX) y demasiado lento para acceder al nivel concreto que quisiéramos. Al final terminó siendo un nivel más (nivel bonus)

⚫ Se descartó totalmente la funcionalidad de la Memory-Card puesto que uno de los mayores problemas que tuvo FADVX fue que debido a su alta dificultad, la mayoría de jugadores no alcanzaban a ver más que el primer nivel. Todos los niveles están desbloqueados desde el primer momento.

⚫ El nivel de la feria de Albacete iba a tener una noria gigante girando (es una idea que tenía en mente desde hace muchos años). No obstante, no supe ver como hacerla encajar con el nivel, y lo más que podía hacer es que nos ayudase a subir a cierta altura, aunque eso forzaría a añadir plataformas en el aire que no encajaban con el resto de nivel basado en el recinto ferial real en tierra.

⚫ La batalla final con Duolingo fue descartada totalmente por todo el tiempo que llevaría implementarla. En ella Duolingo se enfrentaría a Flappy con la escusa de: -"Flappy, ¿Cuanto tiempo llevas sin repasar tu nivel de esloveno?" A lo que Flappy contestaría que quien c**o es él y que para que iba a querer él aprender esloveno, enfadando a Duolingo e iniciándose así la batalla. Algunos de los samples de Duolingo al ser atacado por Flappy serían cosas inesperadas como: -"¡Auch!... que en japones se dice: (sonido de orgasmo)"

⚫ También contaría con una animación inicial al iniciar el juego mostrando a Flappy y su chica hablando en una cueva sobre su futuro con lluvia de fondo usando el motor del juego. En su lugar hice un video de repaso de todos los Flappy Adventures, que fue una idea de última hora y que me pareció una idea muy acertada para toda la gente que me preguntaba por: "¿Y donde están el Flappy Adventure 1 y 2?". Hacer la animación con el motor me habría llevado mucho tiempo para la poca gente que realmente le prestaría atención.

⚫ El juego planeaba tener más objetos dinámicos, pero con solo 5 niveles y un objetivo tan simple para completar los niveles (recoger las 30 monedas y llevarlas con la chica) me pareció innecesario.

Aun así, con todos los recortes, estoy bastante contento con el resultado del juego, que espero que con suerte lleguen a probar unas 10-20 personas, y es que no debemos olvidar que "Flappy Adventure X" fue un autentico fracaso en su recepción. Aunque fuese una obra maestra, al final si no tienes alcance, de nada sirve! Y como ya sabéis, no tengo ni los medios, ni la popularidad en redes sociales ni para que incluso los más fans de PS1 sepan siquiera de la existencia del proyecto. En este punto en 2026 solo hay 3 grandes proyectos para PS1 terminados o en desarrollo. El primero, Flappy Adventure 3 (obvio), el segundo, un port de Super Mario 64 para PS1, y por último un juego aun sin titulo desarrollado por Elias Daler (quien también hizo un minijuego para PS1 bastante bueno llamado Yume Nikki).

A día de hoy actualmente, hay miles y miles de personas siguiendo de cerca estos dos últimos. Una lastima que Flappy Adventure 3 jamas tendrá ni la milésima parte de ese seguimiento ni de cerca, quedando olvidado para siempre en la deep-web

Por último como curiosidad deciros que en el Nivel 1 hay una esquina "buggeada" donde quise poner al limite la colisión del Flappy Engine 3, ¡a ver si la encontrais! ...Ah, y que al igual que en Flappy Adventure 2 y Flappy Adventure X, los modelos del motor Flappy Engine son diseñados mediante el mítico Google SketchUp

Lenguaje LOGO, el "Scratch" de los 80s y 90s

Hoy día para enseñar programación por primera vez a niños (y no tan niños) es habitual usar Scratch, haciendo de la programación algo más visual 

Pero... ¿Que alternativas había antiguamente en los 80s y 90s antes de Scratch? Pues había un lenguaje muy popular, creado en 1967 llamado LOGO, en cual aun siendo de texto, tenía comandos muy simples y la salida era bastante visual al igual que Scratch. En este caso se trataba de hacer dibujos moviendo un puntero representado por una tortuga, de ahí que también se le conociera como "El lenguaje de la tortuga".

Pues queriendo recordar este lenguaje, no solo hice una adaptación al lenguaje C de la tortuga hace unos años, sino que también recientemente encontré una versión online de LOGO bastante buena y que os recomiendo: Turtle Academy.

Pues bien, aunque el lenguaje LOGO es bastante limitado al ser ser de finalidad didáctica, con el único objetivo de hacer dibujos sencillos, usando esta web decidí poner la tortuga al límite, y hacer los programas más bizarros, aquí os los muestro, tenéis los links a los programas haciendo clic en los títulos:

3D game engine voxel space

Os resultará bastante familiar. Sí, se trata de la misma demo que hice anteriormente para la GameBoy Advance, aunque en esta ocasión bastante limitada por la velocidad del interprete LOGO. Aun así el simple hecho de generar pseudo-3D con la tortuga de LOGO es una verdadera locura

Bad Apple!!

Si generar pseudo-3D en LOGO no fue ya suficiente, en esa ocasión genero el FMV completo de "Bad Apple!!" en tiempo real. Los frames están almacenados como un array de números con un número para cada scanline en el que cada número representa los bits de cada pixel (blanco/negro). En esta ocasión y para contrarrestar la lentitud de la tortuga de LOGO para pintar los frames, pongo la tortuga en modo "window" (cuando alcanza un limite, por ejemplo abajo sale por el opuesto, en este caso arriba) le seteo un angulo muy pequeño y lo hago avanzar únicamente en linea recta durante toda la ejecución del programa. De esta forma, la tortuga dibuja las scanlines automáticamente con entrelazado, y lo único que tengo que hacer es cambiar el color conforme avanza recto. ¡Ingenioso y efectivo!

QR text input generator

Aunque los QRs parezcan sencillos, la generación de los datos y la corrección de errores llevan algoritmos complejos. Realmente fue bastante difícil crear este programa con todas las limitaciones de LOGO, pero finalmente lo hice.

3D Raytracing Sphere

¿Raytracing de primitivas 3D en LOGO? jajaj ¿es un chiste? ...Ah ...pues no, no lo es. No hay ningún truco, es raytracing de verdad. Va bastante lento como podeis imaginar, pero claro, hay que recordar lo absurdo que es ejecutar algo así en LOGO.

Interactive maze game

Decompilando el motor LOGO de Turtle Academy descubrí que habían funciones indocumentadas (y rotas, todo hay que decirlo) que permitían obtener la posición del ratón, y los botones del ratón. Que mejor manera de aprovecharlo que haciendo un juego de laberinto interactivo usando un algoritmo de detección de colisiones 2D. Muy probablemente el primer juego interactivo hecho en toda la historia de LOGO.

JS code Injection

¿Vulnerar el sandbox de ejecución de LOGO y ejecutar código JavaScript a través de instrucciones LOGO en Turtle Academy? ¡No, eso ya no hay quien se lo crea! Espera... ¿Eso es un canvas? ¿De donde viene esa música? Podría robar cookies, hacer peticiones XHR para darme autolikes a mis programas,... Pero como mi epoca jaker ya terminó, en lugar de eso os dejo con esta demo re-shula

3D fast engine

Puesto que los programas en Logo se ejecutan bastante despacio, este programa simple inspirado en el motor de Doom permite mostrar polígonos de colores sólidos a full-fps

Y por aquí lo dejamos... Tenéis más programas en mi perfil de Turtle Academy.

Creamos el mejor "Crack No CD" para un juego retro (Tarzán)

 Descarga Tarzan PC Portable aquí.

Aunque el tema del crackeo es un tema delicado, si que es verdad que hay veces donde puede estar medio justificado en abandonware y PCs que ya no disponen de lector de CD. El problema es que estos cracks no siempre son del todo fiables (algunos incluso pueden llevar algún regalito), y los creadores de estos cracks nunca revelan detalles de como lo hicieron, permaneciendo ademas en el anonimato mediante un pseudonimo.

Pues por primera vez, y con motivos didácticos, vamos a crear nuestro propio crack de código abierto para un juego abandonware: Tarzán de Disney Interactive.

Pues bien, este juego aunque copia todos los archivos del juego al disco duro al instalarlo, requiere tener el CD insertado para poder jugar. Si abres el juego sin el CD aparece la siguiente pantalla y no permite jugar

Pues tras un breve análisis, detectamos que existe un flag en memoria en 0x837A24 que indica cuando el juego original esta insertado, y buscando la rutina que setea este flag encontramos lo siguiente

En el primer call el juego comprueba que hay un CD insertado y que contiene determinados archivos, haciendo luego comprobaciones adicionales en el segundo call. Pues bien, nosotros queremos setear siempre ese flag sin hacer todas estas comprobaciones, así que reemplazaremos todas las instrucciones hasta el mov del final por nop.

"TARZAN.EXE"+A39C9: //CD Check db 90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90

Y tampoco nos olvidemos de dejar nuestra firma ;) reemplazaremos el mensaje de CPU con MMX ya que en 2024 no es que nos aporte mucha información

"TARZAN.EXE"+1050E0: //Crack NOCD signature db 'CRACK NOCD JUANMV94',0 "TARZAN.EXE"+8FF33: db 90,90,90,90,90,90,90,90,90

Y... voilà. ¡Crackeo completo! Ya podemos jugar sin CD

FIN

Pero... Esperad un minuto... ¡El juego no tiene música! Resulta que el juego es un CD mixto y la música se encuentra en los distintos tracks del CD.

Y aquí es donde sacamos el armamento pesado, y procedemos a hacer una locura que a ningún cracker se le ocurriría hacer...

Vamos a reescribir las rutinas del juego que leen las pistas del CD, para que lean ficheros MP3 en su lugar ¡y todo ello en puro ensamblador!

Esto lo hacemos usando la librería WinMM que ya usaba el juego, concrétamente usando comandos MCI.

Pues bien, tenemos que localizar las funciones del juego de "reproducir el track XX", "parar CD",... y reescribirlas, aparte de almacenar un handle al archivo MP3 que se este reproduciendo en algún sitio. Nos quedamos con lo siguiente:

define(MUSHANDLE,1051C8) "TARZAN.EXE"+89020: //Stop track push 00 push 00 push 0804 //MCI_CLOSE push ["TARZAN.EXE"+MUSHANDLE] call dword ptr ["TARZAN.EXE"+AF234] //WINMM.mciSendCommandA mov ["TARZAN.EXE"+MUSHANDLE],00000000 ret "TARZAN.EXE"+88FB0: //Disable music call "TARZAN.EXE"+89020 //Stop track ret "TARZAN.EXE"+89070: //Request track mov eax,[esp+04] push 00 push eax call "TARZAN.EXE"+89170 //Play track add esp,08 ret "TARZAN.EXE"+89170: //Play track mov eax,["TARZAN.EXE"+12A5C4] test eax,eax //Music enabled? je RETPLAY sub esp,0C //Alloc 12 bytes for file name push [esp+10] //Track no push FILENAME //File name template with %02d lea eax,[esp+08] push eax call "TARZAN.EXE"+A4190 //sprintf call "TARZAN.EXE"+89020 //Stop track //push MCI_OPEN_PARMS to stack push 00 //LPCTSTR lpstrAlias; lea eax,[esp+10] push eax push MPEGVIDEO //LPCTSTR lpstrDeviceType; push 00 //MCIDEVICEID wDeviceID; push 00 //DWORD_PTR dwCallback; push esp //MCI_OPEN_PARMS push 2200 //MCI_OPEN_ELEMENT | MCI_OPEN_TYPE push 0803 //MCI_OPEN push 00 call dword ptr ["TARZAN.EXE"+AF234] //WINMM.mciSendCommandA mov eax,[esp+4] //store handle mov ["TARZAN.EXE"+MUSHANDLE],eax push MCI_PLAY_PARMS push 00010000 //MCI_DGV_PLAY_REPEAT push 0806 //MCI_PLAY push [esp+10] call dword ptr ["TARZAN.EXE"+AF234] //WINMM.mciSendCommandA add esp,2C RETPLAY: ret MCI_PLAY_PARMS: dd 0 //DWORD_PTR dwCallback; dd 0 //DWORD dwFrom; dd 0 //DWORD dwTo; MPEGVIDEO: db 'mpegvideo',0 FILENAME: db 'MUS/%02d.MP3',0

* Os habréis fijado que hay una función que solicita reproducir un track, y otra que procede a reproducirlo. Esta primera función realizaba varios checks del CD que no nos interesan, así que la re-implementamos de forma que únicamente re-ordenará los parámetros y llamará a la segunda función sin realizar ningún check.

* La función que silencia el audio del CD al des-habilitar la música en el menú de opciones la simplificaremos a simplemente parar la reproducción. No es el mismo comportamiento exacto, pero nos vale.

* La función que reproduce el track comprobará que la música este habilitada en el menú de opciones, y convertirá ese numero de track en un path a un archivo MP3 con sprintf, de forma que el track 2 sea por ejemplo "MUS/02.MP3", lo cargará y lo empezará a reproducir de inmediato en modo repetición, habiendo parado previamente la reproducción previa en caso de existir.

¡Y ahora sí! Extraemos los tracks del CD a MP3 y ya podemos jugar a nuestro juego con la música del CD original en un PC sin unidad de disco.

Hacedme saber si queréis más contenido como este en los comentarios