¿engañar? no, no, joder. como explico en el blog, es básicamente un ejercicio de demostrar visualmente cuan poco hace falta para crear una animación. enseñar código, fuente o binario, no suele ayudar. pero enseñar una imagen de 9x9 pixels, que se crea en cuestión de minutos como se ve en el video, es mucho más gráfico y puede ayudar a entender cuan poco son 224 bytes, y cuánto se puede extraer de ellos. el picking de colores no lo hice de memoria, o es que alguien pensó que tengo los opcodes en mi cabeza y tengo también una vista de águila que discierne valores numéricos en los colores?
Para los que no se crean que puedes crear una animación en 224 bytes (que es lo que ocupa en verdad el ejecutable, aunque tuve que añadir un byte extra vacío para que el número fuera múltiplo de 3), aquí va el código. es código de x86 en modo real (16 bits), lo cual significa que funciona de forma nativa en Windows XP, pero no en Vista ni W7 (pero puedes rularlo mediante DosBox). Para los que saben poco de programación, un .com es un ejecutable de MsDos con código binario plano. No hace llamadas al API de Windows, ni OpengGL ni ninguna otra librería externa, porque es eso, un programa de MsDos, y en aquella época no exitía Windows. La BIOS (a la que se accedía mediante la interrupción "int 0x10") se encargaban de implementar el cambio de modo grafico. El hardware de la targeta de video VGA (accedido mediante el puerto "out 0x3c8") se utilzaba para elegir los colores de la paleta. El resto, es ya manipulación de la memoria de la VGA (dirección 0xa000) para dibujar directamente las imágenes en la pantalla mediante manipulación de los bytes individuales de cada pixel.
fild word [bp+5] ; x
fild word [bp+3] ; x y
fld st0 ; x y y
fmul st0, st0 ; x y y^2
fld st2 ; x y y^2 x
fmul st0, st0 ; x y y^2 x^2
faddp st1, st0 ; x y y^2+x^2
fsqrt ; x y r
fidivr word [bp+1] ; x y d/r
fistp word [es:di+0] ; x y
fpatan ; a
fimul word [bp+0] ; a*128/pi=u
fistp word [es:di+1] ; x y
Hola, soy Iñigo, el programador de la parte visual y de Elevated, aunque no el único, pues el equipo lo formamos dos programadores y un músico. Muchas gracias por los comentarios Voy a intentar aclarar algunas de las dudas que veo hay en los comentarios.
. La demo ocupa algo menos de 4096 bytes (4 kilobytes). Eso incluye todo, es decir, tanto el programa en sí como el contenido. En otras palabras, el motor de visualizado, la lógica la animación, el reproductor de música y el resto de la lógica del programa así como el contenido multimedia que incluye las "texturas", el modelo tridimensional del terreno, la animación/movimiento de la cámara, los datos de sincronización, los datos de secuenciación, los insturmentos de sonido y la partitura en sí misma.
. La música no es MIDI. Los instrumentos/sonidos los generamos mediante fórmulas matemáticas sencillas y técnicas de procesado de señal (que en otros contextos se conoce como DSP), todo por software. No recurrimos a elementos externos al ejecutable para generar sonidos. Por otro lado la partitura la hemos almacenado en un format mucho más eficiente que MIDI. Al iniciar la demo, escaneamos esta partitura y generamos la música através de las fórmulas de los instrumentos. En total, los 3 minutos de música (calidad CD) ocupan 900 bytes. Así que "bufón cósmico", tuércete el culo
Por lo demás veo que todos los que habéis comentado conocéis ya la demoscene, así que no hay mucho más que decir, salvo tal vez dejar algunos enlaces a los vídeos y capturas de más calidad:
#53 inigo_quilez 
Voy a intentar aclarar algunas de las dudas que veo hay en los comentarios.
