You know, I never understood why the space/time beam was termed a "Hardware Glitch." What does it actually is it doing?
Does it throw invalid opcodes to the processor which then proceeds to actually still do work in an undefined way rather than triple faulting?
Does it try to dereference memory that isn't actually there and so it pulls in white noise?
Does it attempt to write to ROM locations and fails with undefined results?
Does it attempt to pull items off of an empty stack and pulls off random noise instead?
Something else?
Well, obviously it doesn't write to ROM locations...that's impossible since it's "Read Only Memory" (hence the name).
What it's likely doing is modifying RAM, modifying bits to tell the game what hasn't been collected, but doesn't modify what's currently collected. I know it does more, but it's really all RAM modification.
Well, obviously it doesn't write to ROM locations...that's impossible since it's "Read Only Memory" (hence the name).
What it's likely doing is modifying RAM, modifying bits to tell the game what hasn't been collected, but doesn't modify what's currently collected. I know it does more, but it's really all RAM modification.
When I hear "hardware glitch," I think, "commands issued to the hardware are undefined by specification," which translates to "very difficult to impossible to accurately emulate," which leads me to believe that it's more than simple RAM corruption.
(Yes, I'm aware that attempted writes to ROM memory locations will fail, what I'm unaware of is when it attempts to write to those locations does it fail in such a manner that it writes to a location on a different memory bank instead?)
Build a man a fire, warm him for a day,
Set a man on fire, warm him for the rest of his life.
moozooh wrote:
By the way, Kejardon, can you shed some more light on the nature of space/time beam and the reasons it fucks up the game that much? How can such a simple thing do that much various effects, all of which mess up everything so badly?
Honestly, not much. I know that the beams use a simple index to find just about *all* their relevant data, and so when you overflow the index (which happens with any combination of plasma + spazer), the game starts pulling data and *code* from essentially random locations. What it does from there is anyone's guess. No, let me rephrase that - what it does from there, nobody can guess. >_> The only way to know would be to read the game's programming.
You know, I never understood why the space/time beam was termed a "Hardware Glitch." What does it actually is it doing?
Does it throw invalid opcodes to the processor which then proceeds to actually still do work in an undefined way rather than triple faulting?
Does it try to dereference memory that isn't actually there and so it pulls in white noise?
Does it attempt to write to ROM locations and fails with undefined results?
Does it attempt to pull items off of an empty stack and pulls off random noise instead?
Something else?
It attempts to perform a DMA transfer that the hardware should not be able to do, I think. Which might end up meaning dereferencing invalid memory addresses and getting 'white noise' (though it's called open bus instead of white noise). I've never gotten a chance to look into the details.
There are no invalid opcodes on the SNES, all of them are defined and work in a specific way. Writing to ROM simply does nothing - some cartridges can support writing to what would normally be ROM addresses (the prototype of Super Metroid was almost certainly one, there are some demo recording routines that write to an empty bank in the ROM).
Pulling items off of an empty stack has a tendency to crash ZSNES horribly bad (at least, the older versions of it I generally use). I have no idea what hardware actually will do when something like that happens.
When I hear "hardware glitch," I think, "commands issued to the hardware are undefined by specification," which translates to "very difficult to impossible to accurately emulate," which leads me to believe that it's more than simple RAM corruption.
Exactly the right idea. From what I hear, emulation authors generally don't spend a lot of time on trying to properly emulate hardware glitches to begin with.
kwinse wrote:
Kejardon wrote:
Kriole wrote:
Samus is damaged by a Rinka in the opening.
That's a script action; no damage.
... it just dawned on me I know way too much about SM.
Joined: 2/12/2008
Posts: 67
Location: San Francisco Bay Area, CA
OmnipotentEntity wrote:
Does it throw invalid opcodes to the processor which then proceeds to actually still do work in an undefined way rather than triple faulting?
There was no such thing as a fault in the 6502 and its derivatives. The processors in those days were very primitive by today's standards!
Kejardon wrote:
Pulling items off of an empty stack has a tendency to crash ZSNES horribly bad (at least, the older versions of it I generally use). I have no idea what hardware actually will do when something like that happens.
Pretty sure that the S register just wraps around. I'm surprised that ZSNES would crash on stack overflow actually.
Kejardon wrote:
Exactly the right idea. From what I hear, emulation authors generally don't spend a lot of time on trying to properly emulate hardware glitches to begin with.
Unless you're bsnes ;)
SNES era games were notorious about relying on hardware glitches and other Things You Should Not Do, since lots of game developers were more electrical engineers than programmers, and Nintendo's manuals weren't that great. (At the risk of posting very old news, I thought I'd mention that the official SNES developer's manual has been available online for a while now. Lots of good information for the curious.)
SNES era games were notorious about relying on hardware glitches and other Things You Should Not Do, since lots of game developers were more electrical engineers than programmers, and Nintendo's manuals weren't that great.
Really? The most I've heard of is reading results from multiplication/division operations early.
evilchen wrote:
that happend to me on a console speedrun :)
Heh. In that case it's fastest to wait for the cutscene to play out. If you leave the room with the Metroid latched onto Samus, your horizontal speed is drastically reduced and the rest of the game takes longer.
If you can get out of the room without the Metroid catching you though, it's definitely a good timesaver.
kwinse wrote:
Kejardon wrote:
Kriole wrote:
Samus is damaged by a Rinka in the opening.
That's a script action; no damage.
... it just dawned on me I know way too much about SM.
I found some very very small potential timesaver today. Basically it is the "subpixel boost" made better. If you turn back and forth just the frame before you are going to do a ledgegrab, with the right position (I believe you have to be just a pixel to the left/right of the platform), you will gain a pixel of distance instead of a half. It could potentially save time where the old subpixel boost was not enough to gain a frame, but I have not found such a place yet (I have only looked in crateria before brinstar though, and ceres),
Here is a video of it being done. You can see that I land at 399.65535, while I would originally land at 398.65535, and the usual subpixel boost would have landed me at 399.32767.
Yay for stupid minor stuff.
No, no, that trick is obviously from the "bullshit" category, as opposed to "I've already discovered this". It means it will only save a meager amount of frames, if any, and won't allow any new shortcuts.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
I have a couple of random questions just for my own curiosity. If anyone's willing to answer them, that'd be awesome.
1) How is Samus's hitbox altered when she's running (as compared to when she's standing still)? If it's wider when running, how does the game handle her running into a wall?
2) When she is running, how does the game alter which frames of the run animation are displayed as she speeds up? I assume that the game is simply dropping frames as she reaches higher speeds; is it selecting from a subset or doing "frameIndex += 2" instead of "frameIndex += 1" or something else entirely?
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
1) How is Samus's hitbox altered when she's running (as compared to when she's standing still)? If it's wider when running, how does the game handle her running into a wall?
I haven't really noticed it altering in any way; the address for hitbox width never changes, no matter if you walk, run, or stand still. When the hitbox encounters a solid obstacle and you contimue to press against it, you will be placed at the closest possible coordinate to the solid block. I.e., if a solid wall block is located at at x=180.0—196.65535, your closest position would be 179.65535 from the left, and 197.0 from the right. It requires some more tampering in Redesign, though.
Derakon wrote:
2) When she is running, how does the game alter which frames of the run animation are displayed as she speeds up? I assume that the game is simply dropping frames as she reaches higher speeds; is it selecting from a subset or doing "frameIndex += 2" instead of "frameIndex += 1" or something else entirely?
Not as she is reaching higher speeds, but rather as she is reaching certain boost levels. Every time it boost counter increments, a certain amount of duplicate frames from her running animation frame set is dropped. Which is why it looks like she's running at mad pace during short charge.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
Thanks! Let me see if I understand:
When Samus "runs" without holding the run button, her run animation plays like 1, 1, 2, 2, 3, 3, 4, 4, or something similar (i.e. for each time her run animation advances a frame, multiple in-game frames pass). As her boost increases, it goes to something like 1, 2, 2, 3, 4, 4, etc, then at maximum boost it's going 1, 2, 3, 4, etc.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Basically, yes. Moreover, the frame that determines the possibility of initial (i.e., first) booster increment seems to be depending on the animation, rather than holding forward button at all, which is the reason for these 3-3-3-4-7 patterns and so on.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
Lol, found a 1/8th of a pixel shorter charge :)
It goes 3-3-4-4-6 (alternatively 2-4-4-4-6), and if you count the first frame you hold forward as frame 0 you hold dash for frame 23-25 (release forward on frame 24), instead of just frame 25.
I can only imagine all the new possibilities opening up with this might discovery (hint of sarcasm detected)!
EDIT:
Okay, scrap that.
3-4-4-4-5, and dash should be held for frame 21-25. It is one and 1/16th of a pixel shorter. It would have been cool to have this bruteforced to see what the actual best pattern is, but I've run out of ideas to make it shorter now anyway.
Well potentially it could save a frame in a few places. At the spark after ridley and the big metroid for example you have to run back a shorter distance after charging, and before botwoon for example you can have a higher speed when speedboosting through the first blocks.
Time for a technical update, I guess. I try to keep it short but still go into detail as much as needed.
Cpadolf wrote:
Here is a video of it being done. You can see that I land at 399.65535, while I would originally land at 398.65535, and the usual subpixel boost would have landed me at 399.32767.
This is the so called "zig-zag" trick that allows you to maintain some horizontal momentum you got before the jump, but in the opposite direction. Because of that it makes perfect sense that it allows to land even further into a platform than the powerranger boost, if well optimized. I actually took advantage of the zig-zag tech in many other situations in my Redesign TAS as well, but in a much more benefitting way than the platform boost, as you will see in the next WIP that should be out soon. But it's still a good find that will allow to eventually save a frame here or there. Well done Cpadolf.
As for the charge optimization, it was clear that adding dash button presses would shorten the overall charge distance, because the greater your running speed is between the stutter walk, the longer your stopping animation would be as well, which surprisingly always results in a shorter distance in the end. However doing so in the early frames will slow down Samus' running animation, which means that it takes more time until the first speed boost level is reached, making you end up with a longer charge distance anyway. But apparently the running animation speed isn't affected if using dash in the later frames, which for some reason I never bothered to try, so it can still be used to slightly shorten the distance. Too bad that it still won't allow you to get a charge in places you previously couldn't with the older tech, as that would require to shave off almost one more block (they consist of 16 pixels), which is just too much to become possible. But we don't have to worry about it in most runs anyway, as there are no places other than the X-Ray charge where it would truly be of benefit as far as I know.
This is the so called "zig-zag" trick that allows you to maintain some horizontal momentum you got before the jump, but in the opposite direction. Because of that it makes perfect sense that it allows to land even further into a platform than the powerranger boost, if well optimized. I actually took advantage of the zig-zag tech in many other situations in my Redesign TAS as well, but in a much more benefitting way than the platform boost, as you will see in the next WIP that should be out soon. But it's still a good find that will allow to eventually save a frame here or there. Well done Cpadolf.
Yeah, I understood that it was the temporary "momentum boost" from turning around that made it work, and I have used the zig-zag trick in both my 100% run and in SM:I (not to mention that it is what allows to get stuck far enough into the door when skipping the statue room without speedbooster).
Saturn wrote:
However doing so in the early frames will slow down Samus' running animation, which means that it takes more time until the first speed boost level is reached, making you end up with a longer charge distance anyway. But apparently the running animation speed isn't affected if using dash in the later frames, which for some reason I never bothered to try, so it can still be used to slightly shorten the distance.
You can use it in the early frames as well, depending on how the stutter pattern you use looks. If it starts with 2 then holding dash for the first 3 frames will prolong the stopping animation without delaying the first booster check (and if you start with 4 then holding dash for frame 1-4 will help). But the optimal pattern I found didn't get any use of this. Either the game only puts in "extra frames" in the running animation at specific points, or it only does it when you have been running for a set amount of time (don't know which), so that's the reason dash can be held in the last few frames.
Oh, and it is great that your next WIP is nearing completion!
Yeah, I understood that it was the temporary "momentum boost" from turning around that made it work, and I have used the zig-zag trick in both my 100% run and in SM:I (not to mention that it is what allows to get stuck far enough into the door when skipping the statue room without speedbooster).
Right, there are many opportunities for that trick to be used in the original game as well, as you guys showed.
Cpadolf wrote:
You can use it in the early frames as well, depending on how the stutter pattern you use looks. If it starts with 2 then holding dash for the first 3 frames will prolong the stopping animation without delaying the first booster check (and if you start with 4 then holding dash for frame 1-4 will help). But the optimal pattern I found didn't get any use of this. Either the game only puts in "extra frames" in the running animation at specific points, or it only does it when you have been running for a set amount of time (don't know which), so that's the reason dash can be held in the last few frames.
Ahh, I see now. The additional dash-boost is apparently only of benefit in the final stutter only, not during the early ones even if you use it in a way that wouldn't delay the running animation. Good to know.
And yeah, the next WIP is on the way, as I finally finished all the necessary tests for the later parts. For those who are curious, but without spoiling too much, it will also introduce a totally new discovery, that I accidentally found just a couple of weeks ago, so there will be new stuff available for everybody, even for the experienced SM-TASer. ;-)
And yeah, the next WIP is on the way, as I finally finished all the necessary tests for the later parts. For those who are curious, but without spoiling too much, it will also introduce a totally new discovery, that I accidentally found just a couple of weeks ago, so there will be new stuff available for everybody, even for the experienced SM-TASer. ;-)
Uh, is it something that could save time for all SM TASes? I kinda have to know, since I don't want to venture further into any runs I am making if I have to redo them because of it.
