Experienced Forum User, Published Author, Active player
(261)
Joined: 12/29/2014
Posts: 16
Has there been any consideration as to whether this is an appropriate game/goal for publication? If this is mostly just Lion King but with an infinite jump hack, you could do that with any game.
Outside of that, I have optimization concerns considering there have been many well optimized runs of this game published. Given the amount of reference material, there isn't much of a reason for any non-infinite jump section to be slower than the runs of the real game. One easy example is the setup for the Be Prepared clip, and then not doing any RNG manipulation for the geysers. The run in the encode immediately loses 2 eruptions compared to the published run. There are even more possibilities for eruption skips on top of the published SNES run that haven't been implemented yet, as seen in the Genesis run. There could have been more effort put into at least some entertainment while waiting as well.
There are some errors in the notes:
- Geysers erupt 5 times before being capped, not 6
- Swipes don't advance RNG, only random events do. The swipes are a RTA setup to not enter the geyser arena too early.
- You don't really unload the geysers when you run to the right, you're just exiting the range where the game continues the eruption cycles
- It would be more accurate to say that the counters that trigger the eruptions flicker between 1 and 0 because they're put into a waiting state, not that they're RNG values
I know TASVideos has been more lenient towards ROM hacks, but I felt like I had to voice my concern about the standard of what is allowable and that we're not undermining the hard work that has been done in the real game.
Experienced Forum User, Published Author, Active player
(261)
Joined: 12/29/2014
Posts: 16
No problem!
McBobX wrote:
Honestly, I thought it was RNG all along, and I assumed that I will just have to manipulate it inside the fight, as the first attack is always going to be Snail reacting to my shot and go to a spinning pattern. From my testing however, I kept looking at which patterns he does the shortest spins, and I attempted to get them. I think the shortest I got was 1 full spin and half. Note that Snail has to go higher one time, otherwise I will get a third spinning cycle, which I assume the cause of bad spinning pattern.
Oh, I was referring to the spin before the fight even starts, like the spin just before he lands on the ground. I'm unsure if the spins during the fight are on the same cycle, but that one should be manipulable by rearranging the refights (or delaying frames if you complete every fight except Snail without getting the fastest spin, which would be pretty unlucky.) The spin in the first fight isn't as nice to manipulate because all you can really do is tradeoff movement frames for lag frames to land on a different global timer value, or delay frames. The difference between the slowest spin and the fastest is 30 frames according to Hetfield's notes on the 31:15, so it's worth delaying frames for if necessary.
Experienced Forum User, Published Author, Active player
(261)
Joined: 12/29/2014
Posts: 16
Did you verify that the movement in a few of these sections is optimal? I wasn't expecting you to have to double kick in the CH2 elevator, and you didn't alternate walls in the CH4 climb. There are some notes on the X1 Sig 4 climb in the buster only TAS that may be worth looking at.
I don't think you got the fastest shell spin pattern in the Snail refight. The spin speed you get is based on the global timer, and the cycle of patterns repeats every 8 frames. I would recommend doing Centipede first, and then checking Snail after each refight to attempt to get the fastest shell spin without having to waste frames to manipulate it.
Nice Wolverine fight, I wasn't sure how much of a pain it would be to manipulate swipes but I guess it's possible to force them in a buster only scenario? In any% you have to manipulate 7 swipes in a row purely from RNG, so it's nice to see it wasn't so bad here.
Overall nice job, I think there are things that can be done to reduce lag even if the baseline amount of lag is higher on v115 (minor movement variations like jump heights, shooting lemons, for example). A lot of the lag in the wireframe fight is caused by movement and inputs as well, for example holding 3+ buttons at the same time can cause lag. It might be possible to reduce a lot/all of the lag on wireframe by crafting your inputs specifically to reduce lag. If anything, it would be nice to see improved lag reduction in an improvement (or on this submission, since it's new).
Experienced Forum User, Published Author, Active player
(261)
Joined: 12/29/2014
Posts: 16
I went through many more iterations of RNG values/eruption order and couldn't find anything faster, so I'm done looking at this for now. Temp encode has been updated.
Experienced Forum User, Published Author, Active player
(261)
Joined: 12/29/2014
Posts: 16
I don't think this is an appropriate game/goal (or speedrun.com leaderboard, for that matter.) It effectively just adds an infinite jump hack to the game. It would be one thing if the content of the game was changed to basically make it a different game, but that's not the case here. Maybe you could put your effort towards finding new stuff in the real game instead.
Experienced Forum User, Published Author, Active player
(261)
Joined: 12/29/2014
Posts: 16
Nice to see this finally submitted after watching the progress on it! There are minor movement improvements and boss strategy improvements that could be made in the early game (such as Chameleon, as noted in the submission), but it's a great first submission for the branch. Yes vote!
Experienced Forum User, Published Author, Active player
(261)
Joined: 12/29/2014
Posts: 16
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, Active player
(261)
Joined: 12/29/2014
Posts: 16
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, Active player
(261)
Joined: 12/29/2014
Posts: 16
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, Active player
(261)
Joined: 12/29/2014
Posts: 16
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, Active player
(261)
Joined: 12/29/2014
Posts: 16
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.
