Embarrasing Fact: Power suit made by lowest bidder
I figured this was something a lot of people would probably want so I made the code as unobtrusive as feasible. It should work on just about any hack, and if it doesn't work on yours you're probably smart enough to figure out what's wrong.
All this does is make the intro text speed up if you're holding a button. It also speeds up fade-out from the movies - this was necessary actually to avoid some rather nasty glitches.
The patch is for unheadered, unsurprisingly. Source code written for xkas is also attached if you want it.
There's still 2 minor graphical quirks with the patch. One is that the SR388 scene may be slightly misaligned, and another is that the palettes might only finish transitioning 31/32nds of the way so they're a tiiiiiny shade off of 'finished' (just about unnoticable). I decided they're minor enough and I'm not going to fix them.
And with that done, it's rant time.
All this does is make the intro text speed up if you're holding a button. It also speeds up fade-out from the movies - this was necessary actually to avoid some rather nasty glitches.
The patch is for unheadered, unsurprisingly. Source code written for xkas is also attached if you want it.
There's still 2 minor graphical quirks with the patch. One is that the SR388 scene may be slightly misaligned, and another is that the palettes might only finish transitioning 31/32nds of the way so they're a tiiiiiny shade off of 'finished' (just about unnoticable). I decided they're minor enough and I'm not going to fix them.
And with that done, it's rant time.
I started this mini-project early yesterday. It's a pretty simple task to do, and as I expected it only took me a few hours to complete the speed-up change from scratch. Nice and easy.
Then a bunch of other bugs started popping up.
First off was one that I was kinda sorta expecting but was hoping the game was smart enough to handle. I should've known better than to overestimate the game's programming like that. Anyways. The text after Samus picked up the baby metroid finished too quickly. Because of this, the SR388 scene never finished properly. For some reason I didn't know at the time this ended up with the scene continuing on after it would have normally stopped. Samus ran too far left, off the screen, and collided with glitch blocks that crashed the game.
Ok. I knew about the glitch blocks - I've played around with the demos before and ran into them numerous times. So I recognize the problem thankfully fast even though I don't know why the demo isn't stopping. Some investigative work and I figure out that the timer for 'end of demo' doesn't reach 0 before the text ends, and the text sets the timer up for the next demo. Ok then, I need to end the demo early or something. I think about the options available for a while, since I wanted to keep from editing data as much as possible to keep the game easily modifiable with the new code. I test a few possibilities. Setting the timer to 0 doesn't seem to quiiite work since the engine still needs to run a frame after it's reached 0 to clear everything. I try setting the timer to 0 and then running the entire engine as a subroutine - this is horribly bad practice I'm sure but often it works fine anyways with small engines. It doesn't work though, although I've forgotten what went wrong. I try a different approach and just try to force-end the demo.
This is where everything started going horribly, horribly wrong.
The flag for the demo is pretty simple. It puts a 1 in the value when it's on, and a 0 when it's off. Although it reads 0 as off and anything else as on. So I make the text code turn the demo off when it restarts the timer.
The demo doesn't turn off.
I double check it and confirm my code is running. I double check the ram and confirm it's still on. So something else must be turning the demo back on after I turn it off. That's annoying. I check in snes9x's debugger. Something is constantly writing 0001 or FFFF into the demo flag value. While I watch the value I notice something.
The direction the baby metroid is flying seems to correspond to the value being written to the demo flag.
Surely it's a coincidence. I look at the code writing to the demo value and figure out it's part of some sort of entity loaded into RAM (This is badly worded but meh). I turn the entity off. The baby metroid disappears.
THE BABY METROID USES THE SAME RAM AS THE DEMO FLAG TO KEEP TRACK OF WHICH DIRECTION IT'S MOVING
WHYYYYYYYYYYYYYYYYEEEEEEEEEEEEEEE
if anyone ever calls anything I do bad coding practice I will refer them to this and ignore anything else they say on the matter.
At this point it's getting late in the day and I'm starting to doubt that I'll finish it before I go to bed. Actually no, when I found that atrocity I started to doubt I'd ever finish hacking the intro. I'd hacked the demos a small bit in the past and knew the code was rather hackish to begin with but still. Using the same RAM as a vital bit flag to decide which way a sprite is moving... and the bits aren't even independent! There's 16 bits and only 2 real booleans to consider!
Anyways. I try to delete the metroid with the code I'm hijacking as well. It technically works, but the graphic is still around. Sigh. I delete that. Oh, now the egg shell is left over. What. I probably would have been banging my head against my desk but I think I was still in shock from the WHY IS THE RAM FOR A VITAL GAME FLAG BEING USED FOR TWO THINGS WHEN IT USES AROUND $1000 BYTES OF RAM JUST FOR COLORS
Some more deleting later and finally all the sprites vanish as they're supposed to.
Then I get around to testing what if I go to the next screen before the graphics even finish fading from the SR388 scene? The answer: BABY METROID DOESN'T DISAPPEAR. Suddenly I no longer feel bad about the fact that Samus just imprisons the baby metroid and gives it to scientists to study in confinement.
I poke around a bit more then give up around then for the day.
After looking through the stuff some more (WHY DOES THE METROID USE THAT BYTE AS A DIRECTION!?!? THERE ARE LOTS OF FREE SLOTS AVAILABLE AND IT OBVIOUSLY HAS RAM AVAILABLE TO ITSELF WHY USE THE DEMO FLAG?!) I realize that I need to fix this a different way anyways. There are a bunch of other bugs aside from the graphic entities (WWHHYYY) that would take a bunch of hardcoded fixing to solve and I don't want to address them that way. I'm already having a hard time fitting the code for fixing the baby metroid in the optimizations I made - I really need to get the timers to go to 0 and properly close stuff down. However, to do this I need to somehow set the timer to 1 or so a few frames before the end of text. Hrm. At this point I begin to think about bugging Jathys for adding support for this in SMILE, since I remember it's able to edit the intro text and I don't want to make a public patch and not have it be compatible with SMILE's tools. Half-way through asking him about adding support I come up with an alternative idea for fixing it though.
I noticed the timers seem to do something every 4th frame, so I might be able to just speed them up to go to the next 4th frame if a button is held. This didn't work as well as I hoped. Colors only half-way transitioned, sprites didn't always disappear before the next scene, and the TEXT didn't always disappear before the next scene. Unfortunately I can't remember what happened very well around that time, but I do remember thinking several times "I can't believe even Nintendo's programmers made this" (though of course none were as bad as... that...). My source code went through several revisions and entire sections appeared then disappeared as different ideas I tried to fix things half-worked. I felt like I was playing wack-a-mole as I fixed bugs then re-fixed what I was sure was the same bug I had just fixed a while before.
So that is why a simple 2 hour project turned into an almost 2 day nightmare.
I blame the baby metroid.
Then a bunch of other bugs started popping up.
First off was one that I was kinda sorta expecting but was hoping the game was smart enough to handle. I should've known better than to overestimate the game's programming like that. Anyways. The text after Samus picked up the baby metroid finished too quickly. Because of this, the SR388 scene never finished properly. For some reason I didn't know at the time this ended up with the scene continuing on after it would have normally stopped. Samus ran too far left, off the screen, and collided with glitch blocks that crashed the game.
Ok. I knew about the glitch blocks - I've played around with the demos before and ran into them numerous times. So I recognize the problem thankfully fast even though I don't know why the demo isn't stopping. Some investigative work and I figure out that the timer for 'end of demo' doesn't reach 0 before the text ends, and the text sets the timer up for the next demo. Ok then, I need to end the demo early or something. I think about the options available for a while, since I wanted to keep from editing data as much as possible to keep the game easily modifiable with the new code. I test a few possibilities. Setting the timer to 0 doesn't seem to quiiite work since the engine still needs to run a frame after it's reached 0 to clear everything. I try setting the timer to 0 and then running the entire engine as a subroutine - this is horribly bad practice I'm sure but often it works fine anyways with small engines. It doesn't work though, although I've forgotten what went wrong. I try a different approach and just try to force-end the demo.
This is where everything started going horribly, horribly wrong.
The flag for the demo is pretty simple. It puts a 1 in the value when it's on, and a 0 when it's off. Although it reads 0 as off and anything else as on. So I make the text code turn the demo off when it restarts the timer.
The demo doesn't turn off.
I double check it and confirm my code is running. I double check the ram and confirm it's still on. So something else must be turning the demo back on after I turn it off. That's annoying. I check in snes9x's debugger. Something is constantly writing 0001 or FFFF into the demo flag value. While I watch the value I notice something.
The direction the baby metroid is flying seems to correspond to the value being written to the demo flag.
Surely it's a coincidence. I look at the code writing to the demo value and figure out it's part of some sort of entity loaded into RAM (This is badly worded but meh). I turn the entity off. The baby metroid disappears.
WHYYYYYYYYYYYYYYYYEEEEEEEEEEEEEEE
if anyone ever calls anything I do bad coding practice I will refer them to this and ignore anything else they say on the matter.
At this point it's getting late in the day and I'm starting to doubt that I'll finish it before I go to bed. Actually no, when I found that atrocity I started to doubt I'd ever finish hacking the intro. I'd hacked the demos a small bit in the past and knew the code was rather hackish to begin with but still. Using the same RAM as a vital bit flag to decide which way a sprite is moving... and the bits aren't even independent! There's 16 bits and only 2 real booleans to consider!
Anyways. I try to delete the metroid with the code I'm hijacking as well. It technically works, but the graphic is still around. Sigh. I delete that. Oh, now the egg shell is left over. What. I probably would have been banging my head against my desk but I think I was still in shock from the WHY IS THE RAM FOR A VITAL GAME FLAG BEING USED FOR TWO THINGS WHEN IT USES AROUND $1000 BYTES OF RAM JUST FOR COLORS
Some more deleting later and finally all the sprites vanish as they're supposed to.
Then I get around to testing what if I go to the next screen before the graphics even finish fading from the SR388 scene? The answer: BABY METROID DOESN'T DISAPPEAR. Suddenly I no longer feel bad about the fact that Samus just imprisons the baby metroid and gives it to scientists to study in confinement.
I poke around a bit more then give up around then for the day.
After looking through the stuff some more (WHY DOES THE METROID USE THAT BYTE AS A DIRECTION!?!? THERE ARE LOTS OF FREE SLOTS AVAILABLE AND IT OBVIOUSLY HAS RAM AVAILABLE TO ITSELF WHY USE THE DEMO FLAG?!) I realize that I need to fix this a different way anyways. There are a bunch of other bugs aside from the graphic entities (WWHHYYY) that would take a bunch of hardcoded fixing to solve and I don't want to address them that way. I'm already having a hard time fitting the code for fixing the baby metroid in the optimizations I made - I really need to get the timers to go to 0 and properly close stuff down. However, to do this I need to somehow set the timer to 1 or so a few frames before the end of text. Hrm. At this point I begin to think about bugging Jathys for adding support for this in SMILE, since I remember it's able to edit the intro text and I don't want to make a public patch and not have it be compatible with SMILE's tools. Half-way through asking him about adding support I come up with an alternative idea for fixing it though.
I noticed the timers seem to do something every 4th frame, so I might be able to just speed them up to go to the next 4th frame if a button is held. This didn't work as well as I hoped. Colors only half-way transitioned, sprites didn't always disappear before the next scene, and the TEXT didn't always disappear before the next scene. Unfortunately I can't remember what happened very well around that time, but I do remember thinking several times "I can't believe even Nintendo's programmers made this" (though of course none were as bad as... that...). My source code went through several revisions and entire sections appeared then disappeared as different ideas I tried to fix things half-worked. I felt like I was playing wack-a-mole as I fixed bugs then re-fixed what I was sure was the same bug I had just fixed a while before.
So that is why a simple 2 hour project turned into an almost 2 day nightmare.
I blame the baby metroid.
Thread title:
