Autor Tema: Nuevos cracks de juegos clasicos.  (Leído 160464 veces)

josepzin

  • Administrador
  • Commodore Master
  • *****
  • Mensajes: 14683
  • Commodoreador web
    • Ver Perfil
    • Mi blog
Re:Nuevos cracks de juegos clasicos.
« Respuesta #390 en: Noviembre 23, 2025, 02:12:33 »
"Vera Cruz", la verdad no me suena...
www.retroinvaders.com | www.commodoreplus.org  | josepzin.blogspot.com

marcos64

  • Commodore Master
  • *****
  • Mensajes: 2972
    • Ver Perfil
    • http://marcos64.orgfree.com/
Re:Nuevos cracks de juegos clasicos.
« Respuesta #391 en: Noviembre 24, 2025, 08:57:34 »
Vives cerca?  :D
http://marcos64.orgfree.com/
Actualizacion 22/4/2018: Actualizada Load'N'Run numero 5 con nuevos TAPs y PRGs.

josepzin

  • Administrador
  • Commodore Master
  • *****
  • Mensajes: 14683
  • Commodoreador web
    • Ver Perfil
    • Mi blog
Re:Nuevos cracks de juegos clasicos.
« Respuesta #392 en: Noviembre 24, 2025, 14:43:29 »
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 :D
www.retroinvaders.com | www.commodoreplus.org  | josepzin.blogspot.com

marcos64

  • Commodore Master
  • *****
  • Mensajes: 2972
    • Ver Perfil
    • http://marcos64.orgfree.com/
Re:Nuevos cracks de juegos clasicos.
« Respuesta #393 en: Noviembre 26, 2025, 09:03:07 »
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  ;D
http://marcos64.orgfree.com/
Actualizacion 22/4/2018: Actualizada Load'N'Run numero 5 con nuevos TAPs y PRGs.

josepzin

  • Administrador
  • Commodore Master
  • *****
  • Mensajes: 14683
  • Commodoreador web
    • Ver Perfil
    • Mi blog
Re:Nuevos cracks de juegos clasicos.
« Respuesta #394 en: Noviembre 26, 2025, 12:21:56 »
Yo estoy bastante mas abajo :P
Al centro de Argentinia.

El que está muy cerca de ahí es @cubelindo
www.retroinvaders.com | www.commodoreplus.org  | josepzin.blogspot.com

marcos64

  • Commodore Master
  • *****
  • Mensajes: 2972
    • Ver Perfil
    • http://marcos64.orgfree.com/
Re:Nuevos cracks de juegos clasicos.
« Respuesta #395 en: Noviembre 29, 2025, 20:15:55 »
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  :D

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

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




EDITO2:

Citar
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... :D
- 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

« última modificación: Diciembre 12, 2025, 21:51:31 por marcos64 »
http://marcos64.orgfree.com/
Actualizacion 22/4/2018: Actualizada Load'N'Run numero 5 con nuevos TAPs y PRGs.

josepzin

  • Administrador
  • Commodore Master
  • *****
  • Mensajes: 14683
  • Commodoreador web
    • Ver Perfil
    • Mi blog
Re:Nuevos cracks de juegos clasicos.
« Respuesta #396 en: Noviembre 30, 2025, 00:23:37 »
No lo tuve en la época y ya luego cuando me llegó no me terminó de enganchar especialmente.
www.retroinvaders.com | www.commodoreplus.org  | josepzin.blogspot.com

marcos64

  • Commodore Master
  • *****
  • Mensajes: 2972
    • Ver Perfil
    • http://marcos64.orgfree.com/
Re:Nuevos cracks de juegos clasicos.
« Respuesta #397 en: Diciembre 03, 2025, 10:35:57 »
Nostalgia ha sacado una version mejorada del crack del Street Rod

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

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



Y ya tenemos arbolito  ;D
http://marcos64.orgfree.com/
Actualizacion 22/4/2018: Actualizada Load'N'Run numero 5 con nuevos TAPs y PRGs.

josepzin

  • Administrador
  • Commodore Master
  • *****
  • Mensajes: 14683
  • Commodoreador web
    • Ver Perfil
    • Mi blog
Re:Nuevos cracks de juegos clasicos.
« Respuesta #398 en: Diciembre 03, 2025, 11:39:31 »
Y ya tenemos arbolito  ;D

Un clásico :)
www.retroinvaders.com | www.commodoreplus.org  | josepzin.blogspot.com