Experienced Forum User, Published Author, Player
(169)
Joined: 12/29/2014
Posts: 7
Link to video
Sorry for the double post, and I won't keep posting every thing I see if it doesn't lead to anything, but in JP 1.0 or 1.1, if you perform this crash by overflowing the list at $1928 with one of the objects associated with Utuboro's death (They forgot to add a check for when the list is full), the game will eventually RTS to the data at $1d09 in RAM. I haven't been able to find a way to write data for useful instructions there, it basically leads immediately into a BRK. But it is a hypothetical way to execute RAM as instructions, so maybe there's some way to make it work, or find some other instance of a similar bug that may be more useful.
Hetfield90 wrote:
Has anyone seen a youtube video of a glitch in Chameleon's stage where X is near the right wall before the body armor capsule rises out of the ground and ends up partially inside of it(or know about the glitch at all)? Someone showed it to me last year right after my v2 100% run was published but I can't find it anymore.
Experienced Forum User, Published Author, Player
(169)
Joined: 12/29/2014
Posts: 7
I want to document this crash here due to the nature of how it works. I made a YouTube video on it but I'll go over it in text as well:
Link to video
It's possible to crash the game in a reproducible manner by loading the second stage brightness controller in Mandrill into the third slot of the section of memory at $7E:1928, entering the boss hallway while the stage is still transitioning from dark to bright, and then dashing in the hallway. This happens because the brightness controller uses the value at offset $12 within the slot as a flag, whereas every other object (as far as I can tell) uses it as an index into a jump table.
When dashing in the hallway, the spark that gets left behind X loads into that third slot, doesn't overwrite the value at offset $12, reads the value (which should be 1 at this point), and uses that as an index into a jump table of 2 byte addresses. This is of course invalid, and the game jumps to a location containing junk data and executes it as code. Unfortunately, the code equivalent of this data is a bunch of STA, ADC, and SBC instructions, before it ultimately hits a BRK and crashes.
Even if this doesn't do anything interesting, I felt it was still worth posting because it's a reproducible way of getting the program counter to jump to an unintended location.
Experienced Forum User, Published Author, Player
(169)
Joined: 12/29/2014
Posts: 7
ALAKTORN wrote:
Like, who the fuck are you two even? Is this Hetfield creating multiple accounts to defend himself? Could someone from the staff verify?
I'm an established Mega Man X speedrunner. I'm stating the facts about my game. There's nothing to defend, as no one from this forum can change anything about how we treat emulator and console.
Experienced Forum User, Published Author, Player
(169)
Joined: 12/29/2014
Posts: 7
But this emulator DOES emulate the game properly. Hetfield does not use any features such as turbo. I'm stating facts here.
Hetfield has both any% and 100% world records, plays on emulator, and uses a keyboard. That is objective, not a matter of opinion.
Experienced Forum User, Published Author, Player
(169)
Joined: 12/29/2014
Posts: 7
Lag in Mega Man X is emulated accurately in snes9x 1.51 rr v7, which is what Hetfield's run uses. It in fact runs at a lower frame rate than SNES (60.099 on console vs. 59.94 on snes9x), therefore there is a net time loss of 4-6 (not 100% sure) seconds for use of snes9x 1.51 rr v7 in this category.
Keyboard has no significant advantage over controller on Mega Man X. This is a 2D game with limited movement and input requirements. There is no way that use of a keyboard could somehow save time for speedruns of this game. If anything, it can be harder to use depending on if you have flat keys or not. For example, on controller you can mash extremely quickly using two thumbs. On keyboard you cannot. Depending on your keys, you may not even be able to mash with one finger as fast as you can on a controller.
Use of multiple keys to shoot/mash is an emulator only feature and therefore is considered cheating. It is not allowed.
Speed Demos Archive is an archive for high quality speedruns done on any official release of a game, not necessarily original hardware. It is not a central rule-making power for the entire community.
snes9x 1.51 rr v7 is allowed for Mega Man X speedruns. It can be and is compared to console because it emulates the game accurately. The Mega Man X community, people who actually speedrun the game, decided that snes9x 1.51-1.53 can be and is compared to console.
