En esos tiempos se ocupaban compiladores comunes. Es probable que CK haya sido compilado con Turbo C de Borland + Turbo ASM a menos que el código ASM venga como inline. CK es 16-bit, funciona en un 286 y las herramientas de Borland recién se dejaron de usar cuando comenzaron a programar para 32-bit (386 / Watcom C/C++)bighead escribió: precisamente eso manolo, no es C++ y es C, pero no es un C estándar. aparte quizás que herramientas privativas o bizarras ocuparon para compilarlo para DOS, quizás el código no es compatible con las herramientas para DOS mas nuevas.
por lo demás, portarlo le quita el sentido al programa ya que la gracia era el motor grafico que movia fluido en las torpes gráficas de pc de ese entonces. lo mejor sería un programa en alguna biblioteca actual que leyera los "paquetes", recordando que las librerías actuales, harían casi todo el trabajo.
Dándole más vueltas, el motor de CK en lo que respecta a la parte gráfica sólo va a servir para DOS, y en otras plataformas tendrán que reimplementarlo. Eso es porque hay dos dependencias fuertes de EGA que son demasiado específicas para que existan en otras plataformas:
* La representación de los pixeles: En el 99.99999% de los sistemas gráficos los pixeles se organizan de forma lineal, en memoria un pixel se almacena al lado del siguiente pixel, y toda la información para reconstruir el pixel se encuentra en el mismo lugar, ocupando uno, dos, tres o cuatro bytes consecutivos (8-bit, 16-bit, 24-bit/RGB, 32-bit/RGBA). En cambio en EGA... afírmense que vienen curvas... se usaba un sistema de "memoria planar" en donde cada byte representaba 8 pixeles, y por lo tanto cada bit de ese byte representaba un componente de color para cada uno de los 8 pixeles. Por ejemplo los primeros 8 pixeles de la pantalla necesitaban 4 bytes NO CONSECUTIVOS donde el primer bit de cada byte representaba los 4 bits que definían el color de ese pixel (4bit = 16 colores), el segundo bit de cada byte representaba los 4 bits que definían el color del siguiente pixel, etc.
Esa representación torcida hacia que si se quería modificar sólo un pixel, había que leer 4 bytes de vram, aplicar un AND para borrar el pixel que se iba a modificar, y luego aplicar un OR para modificiar el bit que interesaba. Finalmente volver a escribir los 4 bytes. En otras palabras, era increiblemente engorroso crear animaciones en pantalla, aunque hay que considerar que la forma que describo es bien carretera.
* Dicho lo anterior, y si aún siguen leyendo, hacer scroll era todo un desafío, ya que si se requería hacer pixel a pixel requería modificar todos los bytes de vram sólo para rotarlos un bit hacia el lado, y a eso había que agregar el mover el bit sobrante al siguiente byte. Por eso los programadores simplemente movían la pantalla en bloques de 8 pixeles para no tener que rotar nada y simplemente hacer un "copy" de la vram a una posición más alla. Y no era por flojera en todo caso, el acceso a memoria era tan lento que hacer una rotación de ese tipo no era suficiente rápida para un videjuego.
Commander Keen sin embargo tenía scroll pixel a pixel. Cómo lo hacían? Detrás de esto está John Carmack y Michael Abrash, el primero creador de toda la saga Wolfestein/Doom/Quake y por lo tanto del género FPS, y el segundo un gran investigador de los sistemas de video de PC (EGA/VGA). Commander Keen usaba - se supone, ya lo veremos en el fuente - un registro especial de video que permitía cambiar el bit que era considerado como primer pixel. Por lo tanto para hacer un scrolling suave se usaba este registro para los primeros 7 desplazamientos y en el octavo se hacía un copy tradicional, volviendo el registro a cero. Ahora suena obvio, pero en esos tiempos fue toda una revolución que hizo famosos a lo creadores de Commander Keen.
Esas dos características ya no existen en sistemas modernos, por lo que todo ese código perderá sentido. Es muy probable que por la organización de la memoria, los datos de los gráficos vengan organizados en planos y habrá que dejarlos lineales... espero que publiquen el código!
Saludos
Some day... somewhere....
