BENEATH A STEEL SKY PARA 286 - 3 AÑOS DE DIVERSION (Y SUFRIMIENTO)
================================================================
El Sabado de mi mala decicion (octubre 2023)
------------------------------------
Todo empezo un sabado de octubre de 2023. Llovia como loco afuera. Yo venia del super de comprar queso rallado porque mi señora estaba cocinando unos fideos. Entre a la cocina, deje el queso, pregunte si hacia falta algo mas y me dijo "NO". Listo, via libre, escape como rata
Estaba bastante al pedo y me dio jugar a algo.Pero.. no podia elegir algo simple...no.. y me acorde del Beneath a Steel Sky, buena aventura grafica, grandes graficos, musica de mierda, que nunca finalize, pero mire de reojo mi hermoso Harris 286-25 y dije: "pfffff, que lastima que esto pide un 386...... simplemente tenia que perder 10 minutos de mi vida en sacar el 486 de la estanteria....". Pero se me ocurrio una idea. ¿Quien necesita un 386+ si tenes ganas de complicarte la vida?
Sinceramente 3 años despues pienso tendria que haberme echado una partida al Sango Fihters o al Sherlock Holmes que lo tenia a medio camino...
Primeros pasos El optimismo y las primeras piñas con la RAM (octubre 2023 - octubre 2024)
-------------------------------------------------------------------------------
* Estimado de avance: Una horita los fines de semana. Mucho mirar codigo en la PC moderna y decir "uuh, donde me meti".
- diciembre 2023: Me baje el codigo original en ASM de Revolution Software (el que anda por github/web abandonwares). Una quilombo asm de registros de 32 bits (eax, ebx, esi, edi, start32code). Imposible/dificil/estupido¿? portar eso a mano directo para un 286. Cambie de estrategia: ScummVM como mapa para entender la logica interna del motor y hacer mi propio codigo de 0 o robar lo que pudiera de los otros dos!! El ASM original quedo solo como juez supremo para sacarme dudas puntuales cuando ScummVM hacia cosas raras, porque realmente no valia la pena meterse a portar
- Entre diciembre 23 y enero 2024: El original, corriendo en modo protegido con su DOS extender, revise y maneja la pantalla de una forma que a mi no me sirve para nada en un 286 y ScummVM ni hablar, el dibuja todo a traves del backend grafico del sistema operativo moderno donde corre. Asi que nada, tuve que escribir directo a la memoria de video modo 13h, 320x200, 256 colores, que es el modo mas simple y rapido que te da una VGA real sin historias, es simplemente escribir el framebuffer del juego, pixel por pixel, directo a donde la placa lo espera.Lo que si implemente para al menos no quedar sin ojos, es doble buffer, para reducir tearing y el parpadeo de graficos al redibujar, pero me consumia mucha ram, asi que hice una alternativa valida, programe un solo framebuffer en RAM que se vuelca con _fmemcpy a la vga, sincronizado con el retrace vertical (video_wait_vsync) para evitar el tearing
- enero 2024: Primer problema gordo. El juego usa compresion RNC (Rob Northen Compression), la misma tipica de los juegos de Sega Mega Drive y Amiga. Me lei toda la documentacion de diferentes web, como unos documentos interesantes Sega Retro, me baje algun descompresor generico de internet (creo q fue dernc). Parecia andar en archivos simples, pero con los archivos pesados del BASS me hacia una maraña de pixeles roto en la pantalla. Claro, el formato tiene su complejidad (arboles Huffman) y el generico no entendia la realineacion de bits exacta que hace este motor. Me llevo horas de sueño decidir mandar a la mierda el generico y portar bit a bit el descompresor exacto de ScummVM (rnc_deco.cpp) a mi rnc_deco.c.
- enero 2024: Despues de varias pruebas y golpes contra la pared, llege a la conclusion 286 no puede descomprimir en caliente mientras jugas, es una tortuga y no le da el cuero. Solucion: arme un script en Python (predecompress_v2.py) en mi PC moderna para extraer los datos de los .dnr/.dsk originales de fabrica y dejarlos ya predescomprimidos en el disco. Ahi renegando descubri que el formato usa entradas de 8 bytes (no 6 como decia un script viejo) y hereda el bit22 del Disk.asm original. Si no respetas ese bit de la cabecera, el juego le mete ancho/alto a cosas que no lo llevan y te rompe toda la intro de video. Con el script corregido anduvo joya.
- marzo 2024: Quise usar el formato sky.cpt de ScummVM, que te da todos los "compacts" (objetos del juego, paletas, tablas, el estado de Foster) ya resueltos en un binario comodo, en vez de ponerme a parsear a mano los 219 archivos .asm/.inc originales por sala. Pero me tope con la pared de los 16 bits: el archivo de la sala 5 (SKY5.CPT) pesaba 84KB y claro el limite absoluto son 64k. Como en el original o en ScummVM ese limite no existe, me invente una solucion mia: parti el archivo en dos (SKY5.CPT con los primeros 476 compacts y SKY9.CPT con el resto reindexados desde 0, usando el numero de sala 9 que estaba libre). Programe el compact.c para que los cargue en cascada y traduzca los IDs en el aire. No muy elegante, lo ideal hubiera sido hacer una red de compacts y salas/situaciones, pero funciono.
Ya decidido a acabar: Opcodes, y el laberinto del Pathfinding (abril 2024 - mayo 2025)
--------------------------------------------------------------------------------------------
- abril-mayo 2024: Me meti a portar el interprete de scripts (el despachador de opcodes del motor Virtual Theatre). Eran 115 opcodes nativos. En el original en ASM era una tabla de saltos directos a memoria. En vez de volverme loco metiendo una cascada asquerosa de "ifs", lo arme elegante en logic.c and mcodes.c: una tabla de 115 punteros a funcion en C indexada directo por el numero de opcode. Si el script pide el opcode 40, salta al tiro a la funcion correspondiente.
- mediados de 2024: Por fin ya empesaba a parecer un juego, asi que decidi implementar el mouse. Directo prorame l driver via INT 33h (la API estandar de DOS que usa el original en mouse.c)
Solucionado el fix de compatibilidad. Tambien reescribi fnNoHuman (un mcode del motor); al principio entendi mal y apague el bit de logica del personaje, rompiendo todo. Tuve que ir al fuente de mouse.cpp de ScummVM para ver que solo maneja el cursor del mouse, no el proceso del muñeco. Lo rehice bien en mcodes.c. No me habia dado cuenta al no tener mouse
- segunda mitad de 2024: Me meti con el Pathfinding (autoroute.c), el algoritmo real de busqueda de caminos que usa el juego cada vez que haces click para caminar (no podes meter linea recta porque te chocas todo). Porté las 281 lineas directo de ScummVM, pero sudando con la aritmetica de punteros con offsets negativos que tenia el juego original. Ademas, el mapa de colisiones (el grid de paredes) venia pensado para 32 bits. Si hacia un casteo directo a puntero en el modelo de 16 bits de Watcom me tiraba basura por temas de alineacion de signo. Tuve que reescribir la lectura en grid.c para que lea byte por byte y reconstruya los datos a mano usando desplazamientos de bits (shifts).
- fines de 2024 / principios de 2025: Me tropeze con un bug que me llevo por la calle de la amargura como dos semanas. En el modo de calculo de ruta (L_AR), Foster se ponia a caminar y cuando terminaba se clavaba en un bucle infinito pidiendo la misma ruta una y otra vez. Se tildaba el juego. Me volvi loco buscando en autoroute hasta que compare contra el flujo de modos del Logic.asm original y vi que mi logic_engine_step estaba mal portado. Lo borre y lo reescribiri como un switch puro basado en la _logicTable de ScummVM. El flujo real volvio y el bucle desaparecio. Tambien portie fnGetTo, fnAr y fnArAnimate que los tenia como stubs vacios y eran los que activaban el modo de seguimiento con animacion.
La intro, gestion ram y el audio (mediados de 2025 - septiembre 2026)
-------------------------------------------------------------------------------------------------
Recta final. Arreglar una cosa rompía tres. Pero ya lo tenia encaminado, habia q terminar el hijo de puta
- mediados de 2025: La intro original del juego es un dolor de huevos para modo real (en especial la secuencia del logo con zoom, descomprime un archivo de mas de 640KB!!!!). Sin ir a xms/ems el limite absoluto es de 640KB de RAM, y con el DOS cargado, drivers, etc con suerte te quedan libres 580-590KB de memoria convencional. Obvio que el original corria con DOS Extender en 32 bits y le "sobraba" ram. Aca explotaba. Invente una solucion propia en rnc_deco.c: el rnc_unpack_streaming. Es una variante del descompresor que en vez de tirar todo a la RAM usa un buffer circular de solo 64KB y va escupiendo el resultado a un archivo temporal en el disco duro.
Igual, el zoom del titulo nunca anduvo fino porque eran demasiados frames completos, tendria que haber reescrito todo solo pensando en este logo, asi que mande la secuencia original a la mierda y dibuje un logo alternativo mas chico en pantalla. Problema resuelto y no se pierde la intro. Seamos sinceros, el logo original estilo 3D cutre de los 90 era un horror de todas maneras
- segunda mitad de 2025: Batalla total por la RAM. La cache de sprites de los personajes crecia sin parar sala tras sala hasta agotar la memoria. El original no tenia este problema porque le sobraba RAM. Programe en mcodes.c una cache de sprites propia con presupuesto fijo en KB y algoritmo de vaciado: si se pasa del limite, quita de ram el sprite mas viejo. Eso me metio un bug que no me di cuenta al principio, porque la cache de sprites y el puntero del "ultimo sprite usado" a veces apuntaban al mismo bloque; lo arregle metiendo una bandera para saber si el puntero era prestado o propio. Tambien descubri que el orden de reserva importaba: si la cache crecia primero, dejaba sin espacio al buffer del fondo de pantalla de la sala. Lo solucione forzando a cargar el fondo primero en mcodes_init_screen0 antes de cachear cualquier sprite.
- principios-mediados de 2026: Ya tenia algo jugable y que no explotaba, pero mudo. Tocaba tiempo de escuchar algo, aqui practicamente pase del codigo original, y ovbiamente de scummvm, que esta pensado para sistemas modernos, y fui escribiendo todo de 0, inspirandome aqui y alli en los codigos originales para tampoco reinventar la rueda
Primero implemente OPL2 (Adlib), una vez funcional, hice un driver de MT32, y ahi descubri algo grandioso, el juego saca sonidos FX si tienes un CM32L, asi que me puse a investigar como funcionaba, encontre que es a travez del canal 10, nunca se deja de aprender en este mundo
Agrege soporte para FX a traves de la sound Blaster, y de casualidad di que existia un "Enhanced Music Released by JamesWoodcock" asi que no pude resistirme, grabe los OGG a un CDrom e implemente AudioCD, marabilloso.
Hoy (octubre 2026)
-----------------
Tres años despues, metiendo una horita cuando se podia entre el trabajo, la familia y la vida, el juego corre en mi 286. Ahora lo que tengo que hacer es jugarlo!
Asi que viene la pregunta, quien quiere hacer de beta tester con su 286? ![[carcajad]](/images/smilies/nuevos/risa_ani2.gif "carcajada")
