Jump to content

You always blame me! Its not my fault!



The very last programming change I made to Adventure II XE brought me great happiness, because it was a bug fix that, although infrequent and minor, had eluded me.   Giving up on it over the past years of this project, I concluded that it must be a weird timing issue with the Atari Hardware and VBI timing. Something was perhaps changing registers behind the scenes?  Because my code was surely 100% rock solid and correct.  


This was a bug which plagued me for years of this project. I'm not sure if it exists in the 5200 version (probably), but I don't recall it occurring back then.    I spent hours trying to determine why this somewhat infrequent bug would occur.   Then I'd forget about it. But with lots of testing of the game over summer 2020, I started to see it again and too frequently.  I said to myself, "Self, you should be able to figure this out and fix it".   


Description of the bug:   Sometimes when you stab a dragon and kill it, the "Dragon Killed" success music would fire, but the Dragon didn't die.   Literally, it seemed that the DragonState variable didn't get changed to a value of 0.   The code decrements the dragon's hit points (health) for every frame that the sword is touching the dragon.  But somehow the dragon would get down to 0 hitpoints left, but its DragonState would not be 0.    This isn't tricky programming. It all looked fine. I kept blaming "weird Atari hardware timing". 


So with the game done otherwise, and nothing else to do, I decided to attack the problem systematically. You know, like a real programmer would. I tested using the excellent Altirra emulator, setting WatchBytes on-screen so I could track exactly what was happening as I fought the dragon.  I killed the dragon over and over, then hit the Revive key (which revives the dragons too) and fought/killed the dragon again and again.  I was able to get the glitch to happen but not consistently. All the memory locations that I tracked were exactly as I'd expected - correct.  What's going on???


Then I started to review the code in detail. Some of the labels for subroutines in the code were stupid, the code didn't do what I originally had intended back in 2004.  So I changed a few labels to make more sense, to help the analysis.  And then I saw it.     


The code Check_If_Killed_Dragon was executing 100% correctly.  As I always assumed.   But after it, in the same frame, it was immediately falling into the next routine Check_If_Bit_By_Dragon, which checks if the Dragon bit you, and changes the Dragon's DragonState variable to a "2" - which means to chase the player.    


So ... if you killed a dragon and the dragon's pixels were touching your player at the same time, it was inadvertently changing the DragonState from 0 (dead) back to 2 (chase player) ! It wasn't "weird Atari VBI timing" at all .  It was BAD PROGRAMMMING.   Mine!    And, I fixed it.    Now, after Check_If_Killed_Dragon, it jumps out of that logic. It can check if you were bitten the next frame. This simple addition of a Jump fixed the years-old glitch! And I felt ... quite pleased and happy.  The game was 100% finished at that moment.  


Sorry I blamed you Atari 8-bit computer line!   You were just doing what I told you to do. 





  • Like 1


Recommended Comments

There are no comments to display.

Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...