Nuevos cracks de juegos clasicos.

[josepzin]

"Vera Cruz", la verdad no me suena...

[marcos64]

Vives cerca? 

[josepzin]

Estuve viendo en un mapa para estar seguro pero creo que estamos mas o menos a la misma distancia o quizás tú mas cerca

[marcos64]

Me referia a Santa Fe de la Vera Cruz. No se porque me sonaba que eras de esa zona. La edad haciendo de las suyas 

[josepzin]

Yo estoy bastante mas abajo
Al centro de Argentinia.

El que está muy cerca de ahí es @cubelindo

[marcos64]

Extend ha creado un nuevo crack con muchos bugfixes de un super clasico: Aztec Challenge

Juego que, estando lleno de bugs, aun asi tenia un atractivo especial. Me parece que la musica tenia gran parte de la culpa 

Quizas el juego era un poco demasiado ambicioso para la epoca.

EDITO: Un fix del fix https://csdb.dk/release/?id=257823




EDITO2:

Production Info
Submitted by Grue on 11 December 2025
Aztec Challenge

As usual, I used the binary from the original game to make the source code for the game and then proceeded to make fixes.

The original game was clearly coded with a machine code monitor, as the memory management used a lot of NOPs and gaps between the routines. There are strange bugs which suggest that something was patched away by altering the memory with a monitor.

I just wanted to fix the stairs level, but then the usual happened..

There is a heroine in the cover art of the game, and now you can choose to play as her by pressing F7 in the menu. The colour of the hair of the Aztec people is not white/yellow, but I decided to not care.

These notes were made during the development of this fix, some things have been forgotten for sure. My main idea was to not change the game too much, but instead to make some fixes to make the game look less jarring to the eye.

One problem with the original game is that it uses dummy loops for delays, also some levels change the timing as the levels advance. The music is played using the default CIA interrupts instead of the raster irq. When timing the screen by waiting for the proper rasterline, you'll miss the line if the music is playing at the same time. Because of this, I chose to time screens with lda $d011, bpl -. This works quite nicely on PAL systems, but because there is much less time on NTSC systems when the 9th raster line bit is on, you might see occasional problems. This could be solved by using raster irq's instead, but that would have changed the game timings too much in some of the levels.
Choices choices, if someone else wants to take this to the next level, I can share the sources, just ask.

Here is a list of the changes and some other things:

The original game told you to hit fire to start the game between the levels. It didnt react to the fire button instantly or sometimes at all, as the fire button was read between the two dummy loops that flashed the "1 up" text during the requester.
- Changed the dummy waiting loop to check for the firebutton inside the loop.

The Gauntlet
- The initial arrow was shot instantly. It felt unfair and in the end it turned out to be a bug.
- fixed the initial counter to be read from the level's initialization data instead of setting it to #1 which caused the instant shot.
- the original code did eventually set that value correctly after the player had already died.
- When a death occurred, arrows were flashed in the wrong positions before the level was reset.
- disabled arrow sprites on death

The Stairs
- Fixed the scrolling of the stairs
- the original code had 4 bugs
- wrong colors, hires instead of the intended MC mode
- What are the correct colours? The hero has white hair on the gauntlet and stairs levels. Is it because both of the levels are supposed to be yellow?
- Changed the colors to match the pyramid as seen in the gauntlet level.
- People will hate me for this for sure...
- The addional color init routine didnt loop, it just made the wrong color blocks
- D011 scrolling didnt wait for a new frame
- Copying new stairs to the top of the screen while scrolling was done incorrectly.
- The initial 3 stones were always in the same positions.
- Randomized the initial state
- Fixed the controls, the original code was very optimistic and caused anomalies when fire/up/down was used.
- Now just Left/Right works on the stick as intended.
- ntsc testing brought the jerky scrolling back, there doesnt seem to be enough raster time available in ntsc with this method.
- I ended up predrawing the screens and switching the screen pointer instead of printing characters into the screen mem in real time. Scrolling is now nicer on ntsc as well.

The Temple

- Cleared sprite to sprite collisions on init to prevent deaths with no apparent cause.
- Sometimes the hero teleported back the left when it should have not, there was a jump to wrong place in the move code.
- fixed

The Vermin
- Fixed the scrolling
- The vermin screen first scrolls the background characters and then copies the background chars to the same place again
- why? its not necessary and the code seems like it's structured to be copying a more complex scrolling background. Looks like WIP to me
- I'm not talented in pixeling and since the original didnt scroll anything there, I just commented the character scrolling code out.
- The original vermin screen timed the action by using a dummy loop (yes you read it right, what an absolute mess). It's pretty much impossible to fix it to be 100% like the original, so close enough needs to suffice here.
- The Vermin screen updated some of the vermin x-coordinates several times per frame seemingly at random, if it was near the hero.
- this turned out to just be a coincidence, the bug was in the randomization code of the next set of vermin.
- The code for the falling spiders didn't check if the spider had scrolled out of the screen during falling, it just teleported to the right at coordinate 255 instead.
- fixed the original code to check if the x-coordinate had reached zero during falling as well.
- MSB bit handling triggered when the x-coordinate reached zero, causing the sprite to flash for one frame as it teleported behind the left border.
- fixed the check, checking $ff instead of 0

HopAztec
- The right hand death arrow was left hanging in the air after hitting the hero
- Hide it after a hit
- The arrow is a MC sprite, but the MC bit wasnt set for the arrow.
- Fixed
- The color of the hero's clothing changed from white to yellow on death
- Fixed

Piranha
- The hero is split in two
- The collision detection is broken this way, and cannot be fixed without recoding the whole logic.
- Changed the splashes of the piranhas to red when they snap the hero.
- it's done in a random order and only if a "coin flip" hits.

The Bridge
- A piece of the bridge disappeared at the msb bit change.
- The reason was the check for zero, if the x-coordinate reached 0 and the msb was in, it turned off and the sprite instantly teleported behind the left border causing a momentary bridge piece to flash on the screen. Changed the code to change the msb when the coordinate reaches $ff instead.
- The color of the hero's clothing changed from white to yellow on death
- Fixed

General changes / fixes

- The game uses decimal mode for counting the score, but the irq routine didnt have cld at the start of it, which can cause anomalies, mostly in the music and sfx department.
- Added cld at the start of the irq-routine.
- A lot of initialization bugs here and there, which were way too numerous to even remember.
- A lot of unneeded data was removed and tidied up. I think this must be the smallest version of Aztec challenge there is.
- not necessary anymore as the heroine gfx got added.
- Tidied up the transitions, now it turns the screen off when the screen mode is changed etc.
- F5 key for B&W mode
- This was a childhood trauma. I had an old b/w tv connected to my C64 with an rf-cable, and you couldn't see the piranhas. So you just died without any apparent reason on that level. When I saw that at my friends place on a color tv, I understood why I was dying all the time...
- The character case change is now locked
- NMI (hitting restore) restarts the game
- Turned sprites off at the init.
- Added rand8 from Codebase64 for a better random source than dc04 reads, and applied it to the places where it matters.
- Introducing the better random algorithm made the game a lot less predictable and perhaps more difficult.
- Added alternative Heroine sprites, you can activate these by pressing f7 in the menu.
- This is a one way change as in real life, there's no going back.

About the music

It is what it is, the music changes in the game as the player advances beyond certain pointsin the level.
- when the music data changes, a pointer address is changed but the index is not (this is an intentional ugly hack in the original code)
- when the player advances more, the waveform is changed in the sid but this is not in relation to the note data, it depends on how fare in the level you are.

When you consider this, the music may sound buggy. But it is what it is. I think there should be a completely different music routine to have it work properly, and it's out of scope for this project.

Phew, there were quite a lot of bugs there, and I'm sure theres still a ton left. Even though it is a beloved classic game, that doesnt mean it was bug free.

Bugfix fix notes:

- When restarted the game, the Cosmi logo was corrupted.
- fixed
- It was possible to choose heroine again after restart.
- fixed
- Music broke completely after death at piranha level
- fixed
- There was still arrow left hanging in the air in hopaztec if msb bit was on on arrow sprite
- fixed

- On the stairs, starting of the screen was ugly and it was super ugly when restarting the level after death.
- Several possible reasons for that, but I tried to fix it by blanking the screen momentarily after death.
- this calmed down the screen and even it wasnt the main cause of the ugly execution I decided to leave it.
- Start of the stairs was randomly ugly, the reason was that screen was painted without waiting the raster line being out of visible area.

- ended up fixing all the levels by blanking screen at the start and and then paint the screen before enabling it again.
- I was going to do that already earlier but totally forgot about it...
- some levels may still show some inpurities at the start, like in the gauntlet no sand at the lowert part of the screen for the first moment of the level
- also piranha level drawing is boiled into actual playcode so it is what it is.

- On the bridge level hero sprite flashes occasionally when moving upwards, its hard to avoid as the screen update is not synced to $d012, and if we start to wait for $d012 lines for the sprite writes, timings mess up on later levels when it gets a lot faster.



Tools used:
6502 Bench
64tass
retrodebugger
VSCode editor
Exomizer

[josepzin]

No lo tuve en la época y ya luego cuando me llegó no me terminó de enganchar especialmente.

[marcos64]

Nostalgia ha sacado una version mejorada del crack del Street Rod

Onesided, fixed glitch in graphics when changing screen modes, color fixes and text fixes

https://csdb.dk/release/?id=257635



Y ya tenemos arbolito 

[josepzin]

Y ya tenemos arbolito 

Un clásico

[josepzin]

Seguro esto ya se publicó por este hilo, pero a raiz del programa del Dany que se termina el Impossible Mission, estuve leyendo las mejoras de esta versión "Revisited" y la verdad es para sacarse el sombrero!!

Impossible Mission Revised
https://csdb.dk/release/?id=242553&show=notes#notes


Aquí va una traducción de todo lo que hicieron, espectacular. Ya solo que marque en el mapa las habitaciones que falta terminar de revisar es una gran ayuda, pero tiene muchas cosas mas.

# Impossible Mission Revised
**Basado en la versión original de Australia (AUS).**

El juego no tenía protección de disco, pero quedaban al menos 3 "bombas" en el código. El programa verifica si la dirección `$d024` contiene `$0a`; si no, se bloquea. El juego realiza un `JSR` (saltar a subrutina) al registro CIA `$dd03` donde almacena un `$60` previamente en el código, el cual luego se sobrescribe. Finalmente, tiene una llamada IRQ a la *zero page* solo para actualizar el contador de frames, que se sobrescribe al reiniciar. Todo esto ha sido eliminado y el código se ha limpiado.

Es un movimiento audaz intentar mejorar un videojuego perfecto; uno podría pensar qué demonios se podría mejorar. Revisé todos los *ports* del juego en YouTube y noté que, en la versión de BBC Micro, la pantalla temblaba cuando el héroe caía desde una altura considerable. En la versión de PlayStation, había una función excelente donde el mapa marcaba qué habitaciones habían sido vaciadas tras registrarlas. También encontré algunos errores (*bugs*) y lugares para pulir y hacer el juego aún más disfrutable de lo que era originalmente.

Para ofrecer un mayor desafío, se han rediseñado las plantillas para cortar las piezas de los puzles, de modo que las formas familiares ya no son exactamente iguales. Además, el generador de números aleatorios (RNG) ahora se gestiona de forma que cada partida sea diferente.

Personalmente, estoy muy contento con el resultado; ¡me encanta este juego, y ahora incluso más!

Los "dolores de cabeza" habituales pueden leerse en el registro de cambios a continuación.

---

### CAMBIOS:

* **Generador de Números Aleatorios (RNG):** Se insertó el algoritmo X ABC de *codebase64* en el código base.
    * Al inicio del juego, debes interactuar con el joystick 2 para añadir entropía al inicio del RNG.
    * El jugador debe presionar el botón del joy2 y, al soltarlo, la semilla del RNG se establece con la información de la interacción del usuario.
* **Rutina de espera:** Se cambió el bucle de espera vacío por una espera basada en `$D012`, en lugar de quemar ciclos de CPU para medir el tiempo.
    * Esto corrige los tiempos en sistemas con aceleradores de CPU.
* **Reloj del juego:** Ahora se ajusta con información PAL/NTSC. 1 segundo equivale a 60 frames en NTSC y 50 en PAL.
    * El juego original corría más lento en sistemas PAL, ya que un segundo se contaba como 60 frames en todas las versiones.
    * Usé la detección PAL/NTSC del juego para configurar el valor del tic del reloj.
* **Efectos de Game Over:** Tras la risa de "Game Over", la pantalla tiembla y se pone en blanco; la pantalla no quedaba centrada y el color negro asomaba por los bordes.
    * Se restauraron los valores por defecto de la pantalla tras el temblor.
* **Audio:** Se añadió código para reproducir los *samples* con más volumen en el chip 8580.
    * En el emulador Vice parece distorsionar, pero suena bien en hardware real.
* **Compresión de datos:** TNT ayudó proponiendo el empaquetado de los gráficos de Elvin Atombender.
    * TNT suministró los datos empaquetados y la rutina de descompresión.
    * La información de 1k de color ahora solo ocupa 157 bytes.
* **Guardado de archivos:** Se simplificó el proceso de guardado.
    * El original era demasiado complicado: primero guardaba "HI2", luego borraba "HI" y renombraba "HI2" a "HI".
    * El nuevo sistema utiliza sobreescritura directa.
* **Memoria:** Las rutinas de IRQ y guardado de archivos se movieron a una zona más baja de la memoria.
    * El guardado funciona ahora con el *Action Replay* activo.
    * El FC3 corrompe la pantalla tras guardar, pero el guardado funciona y puedes reiniciar el juego usando RUN/STOP, RESTORE o ambos.
* **Escena de Game Over por tiempo (Time-out):**
    * Se corrigieron errores donde el último byte del banco era visible y los sprites del ascensor hacían que la escena pareciera rota.
    * Ahora el último byte del banco se limpia durante el temblor de pantalla y se restaura después.
    * El sprite de la pared del ascensor se apaga y el sprite del techo se mueve con la pantalla. La escena se ve mucho mejor.
* **Habitaciones 15 y 20:** Tenían asignado incorrectamente color de alta resolución (*hires*) a teselas multicolor (MC).
    * Se cambió el código de color para mostrar las teselas como MC. Esto corrige lo que considero era un error original.
* **Mapa mejorado:** Si una habitación ha sido vaciada al registrarla, aparece hueca en el mapa del jugador.
    * Esto hace el juego un poco más cómodo de jugar (fue sorprendentemente difícil de añadir).
* **Caídas:** Si el jugador acelera al caer por encima de cierto umbral, la pantalla tiembla.
    * Se implementó un temblor aleatorio de 5 frames en `$d011`.
    * Se añadió un efecto de sonido para el golpe contra el suelo (*thud*).
    * Se corrigió un error del original donde el byte de caída no se activaba al morir, causando procesamiento innecesario del héroe.
* **Formato de hora:** El reloj del juego está ahora en formato de 24 horas. (Dudo que los agentes oficiales usen AM/PM para evitar confusiones).
* **Puzles de notas:** Las habitaciones de puzles de notas ahora están marcadas en el mapa con un patrón de tablero (ajedrezado).
* **Guarida de Elvin:** La puerta de la guarida de Elvin se marca en el mapa, pero primero debes recolectar los objetos necesarios.
* **Reloj de Sprites:** Código finalizado; muestra horas y minutos. (Muestra el reloj en el campo de juego, lo cual fue un dolor de cabeza).
* **Optimización de memoria:** Me quedé sin espacio de nuevo. Se empaquetó más contenido de la pantalla final de Elvin y se movieron bloques grandes de código bajo la E/S (principalmente los encargados de la aleatorización inicial).
* **Contraseñas:** El juego ahora tiene 32 contraseñas diferentes. Se elige una al azar al empezar. (Luego se redujo a 24 para que quepan en una sola página de memoria).
* **Renderizado del reloj:** En habitaciones normales, el reloj se renderiza con caracteres en la esquina superior derecha.
    * No se muestra mientras el jugador registra objetos o en habitaciones de puzles de notas por conflictos con el set de caracteres.
* **Animación de robots:** Nuevos frames de animación por Trurl.
    * Ahora puedes ver la parte trasera del robot si el juego lo elige al azar.
    * Fue muy difícil de añadir porque el juego tenía su lógica muy ajustada a solo 6 frames. ¡Ahora tenemos 12 frames y aún queda algo de memoria!
* **Interfaz:** Corregido un error de color en la interfaz del teléfono en el mensaje "orientation corrected".
* **Diseño del reloj (Sugerencia de "the wolf" de Lemon64):**
    * El reloj corre de 12:00 a 18:00 para que el punto y coma encaje limpiamente.
    * Debido a limitaciones de espacio (16 píxeles), se usaron desplazamientos de bits (LSR/ASL) para crear un espacio de 3 píxeles para el punto y coma entre los dígitos.
* **Tipografía:** Preparativos para cambiar la fuente ROM de Commodore por la fuente "7-up".
* **Punteros de Sprites:** Los sprites extra de los robots se movieron a números de puntero pares para evitar conflictos con la lógica de "mirar atrás" del juego.
* **Desafío:** Plantillas de puzles modificadas para aumentar la dificultad.
* **Puntuación:** Corrección en el cálculo de puntos para contar segundos en el intervalo de 0-6 horas en lugar de 12-18.

---

### Herramientas tradicionales utilizadas:
64tass, Ghidra, 6502 Bench, 010 Editor, Spritepad Pro, Charpad Pro, VSCode editor, Retrodebugger, Vice, Exomizer, CC1541, Dart, DirMaster.

[marcos64]

Aunque no es un juego que a mi me guste, es todo un clasico: Head Over Heels Extended

https://csdb.dk/release/?id=262697

# Diario de Head Over Heels para C64: encajando un clásico de Spectrum

## Cómo empezó todo

Conocí este juego gracias a Barfly y decidí investigar si podía hacerlo un poco más rápido.

La historia de siempre: descifré la cinta original, exporté el binario, lo importé en 6502bench y comencé el arduo trabajo de convertirlo en código fuente compilable.

Después de aproximadamente una semana, había logrado ordenar gran parte del caos del direccionamiento indirecto y localizar la mayoría de las tablas que contenían direcciones que debían convertirse en etiquetas. Esto permitió que el código fuente pudiera compilarse sin demasiados problemas de asignación de memoria.

## Metiendo la IA en el lío

El código del juego resultó ser muy complejo y difícil de seguir, así que en ese momento decidí incorporar IA al proyecto. Tenía una suscripción de pago a Claude Code, de unos 20 euros al mes, porque quería aprender cómo funcionan estas herramientas. Tengo 52 años, una edad demasiado joven como para ignorar la IA si quiero seguir trabajando hasta la jubilación.

Una vez que pude identificar las rutinas responsables de dibujar los gráficos, vi posibilidades de mejora. Pero no había mucha RAM libre disponible, así que decidí eliminar la música y los efectos de sonido para liberar unos 120 bytes de página cero y casi 8 KB de RAM. ¡Un sacrificio bastante drástico! Por supuesto, el juego necesita sonido, pero decidí no preocuparme por eso en esta etapa.

Le pedí a Claude que buscara optimizaciones. Al principio no encontró gran cosa, pero cuando empecé a guiarlo rutina por rutina y a indicarle qué debía buscar, produjo muchos resultados útiles.

Aquí va una pequeña advertencia: la IA no es inteligente en el sentido humano. Es una herramienta, y lo que obtengas de ella dependerá de cómo la utilices. Después de cada cambio sigue siendo necesario verificar y probar todo. A veces los resultados son subóptimos, así que debes entender qué intentas lograr y orientar a la IA hacia otro enfoque.

En resumen, la IA es una herramienta excelente, pero como cualquier herramienta, necesitas entender lo que haces para utilizarla eficientemente. Ahorra muchísimo tiempo y, en general, parece introducir menos errores que yo... aunque no siempre. Tuve que restaurar copias de seguridad más de una vez porque estropeó las cosas hasta el punto de que ni ella misma podía arreglarlas. En parte fue culpa mía por no probar con suficiente frecuencia.

## Las primeras mejoras reales y el primer pánico por memoria

Resumiendo: conseguí ahorros significativos de ciclos de CPU, dependiendo de la tarea. En algunos de los peores casos, las mejoras suponían miles de ciclos.

La desventaja era que me quedaban apenas unos 3,5 KB de memoria libre, así que volvió el clásico pánico por la memoria del C64.

No había forma de incluir la música original, así que estudié la posibilidad de conservar los efectos de sonido. Eso me llevó a la rutina musical. Y vaya desastre.

Me llevó varios días hacerla reubicable. Había saltos definidos dentro de los propios datos de los efectos, código automodificable y punteros a rutinas de efectos.

Al final conseguí convertirla en código fuente reubicable. Claude ayudó parcialmente, pero no pudo descifrar las partes más complicadas, así que esas tuve que resolverlas manualmente.

Volviendo al tema: finalmente logré recuperar los efectos de sonido, pero apenas quedaban unos 200 bytes libres de RAM, y aún quedaba mucho por hacer.

## Exprimir todos los trucos de velocidad posibles

Para los usuarios de C128 activé el modo de 2 MHz en los bordes y durante el renderizado de habitaciones cuando la pantalla está apagada. Esto hace que el juego funcione de forma mucho más fluida.

Los usuarios de Ultimate64 pueden usar el modo turbo con Turbobit activado. El juego funciona sincronizando cuadros cada cuatro fotogramas. También podría funcionar con una SuperCPU real, aunque no lo he probado. Sí funciona con VICE xscpu.

Esto también me permitió limpiar las transiciones. Ahora hay menos parpadeos de pantalla que en el juego original. Además, el juego original mostraba un molesto punto blanco en el borde causado por escrituras constantes de color. Eliminé ese código porque solo se utilizaba en los menús y no afectaba a la jugabilidad.

## Una pequeña mejora de calidad de vida

Añadí soporte para el segundo botón de disparo del joystick.

* Head utiliza el segundo botón para tocar la bocina, si has recogido tanto los donuts como la bocina.
* Heels lo utiliza para recoger y soltar objetos una vez que has conseguido el bolso.
* Cuando Head y Heels están combinados, el segundo botón controla la función de recoger y soltar objetos.

Es difícil hacer mucho más, porque queda muy poca RAM disponible: prácticamente todo está en uso.

## Persiguiendo la versión de Spectrum

En algún momento empecé a preguntarme cómo este juego había logrado caber en 48 KB en Spectrum.

Entonces recordé lo obvio: el ZX Spectrum tiene una resolución de 256×192, frente a los 320×200 del C64.

También me di cuenta de que, con esa resolución, pasar a la siguiente línea del bitmap requiere simplemente incrementar el byte alto de la dirección, mientras que en el C64 hay que sumar un valor de 16 bits para obtener la dirección de la línea siguiente. Esto puede resolverse mediante tablas, pero esas tablas consumen espacio valioso. Cambiar de bitmap a fuentes también permite ahorrar memoria para más optimizaciones.

Actualmente el juego utiliza 32 caracteres por línea y 25 líneas en pantalla repartidas entre cuatro fuentes diferentes. La pantalla original de Spectrum solo tenía 24 líneas de altura.

Por desgracia, tuve que implementar una rutina raster estable para gestionar los cambios de fuente. Como podrás imaginar, ejecutar un juego tan complejo provoca mucho jitter, con todas las consecuencias habituales para las interrupciones IRQ.

Al final no estoy seguro de haber ahorrado tiempo de CPU en este aspecto, porque ahora se consume mucho tiempo en interrupciones. Sin embargo, sí obtuve una gran cantidad de memoria adicional, lo que me permitió añadir código de aceleración en otras partes. Eso sí marcó una diferencia importante.

También tuve que eliminar el bitmap de carga original del juego principal, porque mantenerlo habría complicado demasiado la gestión de memoria. En su lugar, añadí una introducción independiente con la imagen de carga y la música del título que había retirado del juego principal.

## La madriguera del guardado en checkpoints

Luego empecé a investigar cómo guardar puntos de control en un archivo.

Al principio parecía sencillo, porque el juego ya mantenía ranuras de checkpoints y permitía continuar después de perder todas las vidas. Si salías y comenzabas una partida nueva, te preguntaba si querías continuar una partida anterior.

Pero siempre hay alguna trampa.

El juego utiliza toda la página cero y la memoria a partir de $0200, por lo que los vectores de ROM y muchas ubicaciones de la página cero ya están ocupados.

Para solucionarlo, adapté mis antiguas rutinas de carga y guardado para que funcionaran en este entorno tan restringido. Durante la inicialización, el área entre $90 y $CF se intercambia temporalmente y luego se restaura durante las operaciones de disco. Esto también preserva el entorno original del juego mientras se realizan las operaciones de archivo.

Sin embargo, mis primeras pruebas fueron un fracaso total. El juego se bloqueaba incluso cuando las operaciones de disco fallaban.

Más tarde descubrí la causa: había asumido erróneamente que los vectores de carga y guardado estaban en $0320 cuando en realidad se encuentran en $0330.

Tras corregirlo, el sistema de guardado y restauración empezó a funcionar.

Ahora el juego guarda automáticamente cuando recoges un checkpoint ("pez"). Cuando vuelves a iniciar el juego, carga el archivo guardado y te permite continuar donde lo dejaste. Es una funcionalidad completamente nueva para un juego tan grande y difícil.

## Recuperando los niveles originales de Spectrum

La versión original de Spectrum tenía niveles más complejos porque el Z80 podía dibujar y ordenar los gráficos isométricos más rápidamente.

Tras todas mis modificaciones, sentí que la versión de C64 era finalmente lo bastante rápida para intentar utilizar las habitaciones originales. Con los modos turbo activados incluso puede alcanzar velocidades sin ralentizaciones.

El juego ahora incluye el diseño de niveles original importado desde la versión Spectrum, en lugar de las versiones simplificadas de C64 y Amiga que se utilizaban originalmente.

Barfly/Extend probó el juego y confirmó que es posible completarlo con los niveles originales. Esto también lo convierte en la primera persona del mundo en terminar los niveles de Spectrum en un C64.

## Más errores, más correcciones y más momentos de "¿cómo demonios ocurrió eso?"

Por supuesto, nuevamente me estaba quedando sin memoria libre y todavía quedaba al menos un error por corregir y una característica que quería añadir.

La versión de C64 calculaba incorrectamente las habitaciones visitadas. Durante las pruebas, Barfly visitó más de 270 habitaciones al completar el juego, pero la pantalla de puntuación solo mostraba unas 220.

Resultó que había un error en el código original encargado de marcar las habitaciones visitadas, y ahora está corregido. Es al menos un fallo importante menos en el juego original.

También ajusté los colores para que coincidieran mejor con la versión Spectrum.

Pruebas posteriores revelaron que usar la bocina en habitaciones muy cargadas provocaba bloqueos. La solución fue sencilla una vez identificado el problema.

También encontré un pequeño error en el tamaño de algunos textos del menú y lo corregí.

Y hablando de anomalías, después de arreglar esos textos tuve que añadir una directiva `.align 2` al código fuente para evitar que el objeto trampolín se convirtiera visualmente en los gráficos de Heels.

A veces el código se vuelve como un castillo de naipes: resulta peligroso tocar cualquier cosa cuando el diseño de memoria ha sido ajustado al límite absoluto.

## Trucos y limitaciones finales

Generalmente estoy en contra de hacer trampas en los juegos, incluidos los trainers, pero esta vez hice una excepción. El menú Extend incluye una opción para activar vidas infinitas. Si se utiliza, la puntuación final no se muestra.

Originalmente, los checkpoints eran de un solo uso. Consideré que esto era injusto y modifiqué el juego para que siempre utilice el checkpoint más reciente sin retroceder a uno anterior.

Incontables horas y compilaciones fueron necesarias para llegar hasta aquí. Ahora finalmente ha llegado el momento de lanzarlo al mundo.

## Algunas notas técnicas antes del lanzamiento

Se utilizan varios trucos.

Por ejemplo, los objetos inanimados no se actualizan en pantalla en cada fotograma. Esto significa que los gráficos de los teletransportadores solo se actualizan si estás encima de ellos.

Además, si consigues dejar atrapado a un enemigo contra un objeto de manera que no pueda moverse, el juego funciona más rápido porque se omiten los cálculos de ordenación y las actualizaciones de animación para ese enemigo.

Por desgracia, si existe un objeto pez animado situado sobre una pila alta de objetos, el rendimiento puede caer notablemente. Todos los objetos de la pila deben ordenarse continuamente.

De forma similar, cuando los objetos están cayendo también pueden aparecer ralentizaciones mientras el juego calcula qué debe dibujarse y dónde.

Las transiciones entre habitaciones siguen siendo relativamente lentas porque ordenar los objetos de la habitación consume tiempo. Su orden se precalcula mediante tablas para acelerar el funcionamiento general, pero la ralentización sigue siendo perceptible.

Con mucha más memoria libre quizá podrían realizarse más optimizaciones. Sin embargo, dadas las limitaciones del hardware, esto es lo máximo que he conseguido exprimirle.

[josepzin]

Es un juego que a mi me gustó mucho y lo jugué mucho también.

Me leí todo el texto y es ESPECTACULAR lo que hizo... por dios... ojalá se haga lo mismo con otros juegos!!!

Lo he traducido y reemplacé el tuyo en inglés, Marcos. Si alguien quiere leer el original, está en el enlace a CSDb.

¡Tengo que probar esta version!

[josepzin]

Lo acabo de probar... es una mejora en velocidad TREMENDA. Ahora es muchísimo mas jugable y estuve un buen rato recorriendo el mapa, solo se ralentiza un poco en algunas habitaciones.

Que alegría de versión!

[josepzin]

El juego funcionando:
https://www.youtube.com/watch?v=Q-p9bUpom6g