Joined: 11/14/2005
Posts: 1057
Location: United States
Though the realtime gains would probably be a wash using the pause trick, I am sure the in-game savings would be vast. Maybe just enough frames to push it to the next minute mark?
Actually interestingly enough the addresses that keep track of the minute, second and frame counter for the ingame clock freezes once Samus health reaches 0 as long as you keep pausing (and ticks up by 1 when she dies), so the game would be likely to show an incorrect ingame clock at the end of the game, and would probably bring the run to 00:05 if the ending can be triggered somewhat quickly. I'm kind of hoping it will turn out slower though just because of how terrible it will look.
Joined: 11/14/2005
Posts: 1057
Location: United States
Wow, that is very interesting to hear. I had no idea that the clock essentially stopped when utilizing that trick. This would mean that a zero minute final time could be possible if someone had the patience to TAS out the entire game using the pause trick :P
I think 00:02 would be the limit because the earliest you could really start to abuse it would be in Old Mother Brain Room which is reached at about 2 minutes. Maybe 00:03 actually because you need to have health to survive on the elevators so every ride would add a significant chunk of time. Suffice it to say though, I'm not touching that :P
Cpadolf: I don't think you need to worry about in-game time here. Whether you use the death pause trick or not, the final ingame time can be whatever we want. Why not go for 00:00.00? It's just a memory address like any other, so we can set it to any value.
I've been busy with work today, so no progress. But if you (or somebody else) want to speed things up, one thing you could do is to see how quickly you can glitch out of bounds and reach a place where memory.readbyte(0xdc4) is 0x10, 0x30, 0x50, 0x80, 0x82, 0x90, 0xd0 or 0xf0 (that is, one of many relative jump instructions that can be made to work in this situation), and memory.readbyte(0xdc5) is 0x38 (the distance to jump to a copy of the input for controller 1, which will be enough to get us to the real target of 4218). If you can reach that in reasonable time, then we can skip the ammo and OAM requirements (though you still need the beams, of course).
Haha, that's true, I hadn't thought of that :P It should probably be left as is though to get a more honest representation of the final time in comparison to other runs (like the current glitch run), even though the death trick (if faster) will already mess with that a bit. If there's one "extra" thing that should be done I think it would be to set the flag to save the animals.
Anyway there's no rush, I'll probably be working on the death trick version up to GT for more than a week as I'll have less free time going forward and there's a decent amount of stuff to test to optimize health and ammo management up to Norfair.
Cpadolf: I don't think you need to worry about in-game time here. Whether you use the death pause trick or not, the final ingame time can be whatever we want. Why not go for 00:00.00? It's just a memory address like any other, so we can set it to any value.
On that note, the run really ought to go for more than 100% completion.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Cpadolf: I don't think you need to worry about in-game time here. Whether you use the death pause trick or not, the final ingame time can be whatever we want. Why not go for 00:00.00? It's just a memory address like any other, so we can set it to any value.
On that note, the run really ought to go for more than 100% completion.
255% save the animals% 00:00 in game time% no screw attack% UWR :)
Cpadolf: I don't think you need to worry about in-game time here. Whether you use the death pause trick or not, the final ingame time can be whatever we want. Why not go for 00:00.00? It's just a memory address like any other, so we can set it to any value.
On that note, the run really ought to go for more than 100% completion.
255% save the animals% 00:00 in game time% no screw attack% UWR :)
I support this notion. Although maybe having 0% with an ingame timer of 999:99 would be hilarious as well.
Can someone do encodes of the WIPs? I can't power SNEShawk to full speed.
Half-hearted WIP of Cpadolf's WIP: https://dl.dropboxusercontent.com/u/2167374/Cpadolf%20Super%20Metroid%202014-03-10%20WIP.mkv
Not familiar with Bizhawk, so did my best.
Not sure where the movie ends, either (Bizhawk doesn't say a anything?), but I believe I know where it ends.
So consider this a quick and dirty first-hand preview WIP.
Youtube encode maybe coming later...
Cpadolf wrote:
Anyway, I just reached GT in the run I've been working on. It went pretty quickly because so many parts of the run could be lifted with only minor adjustments (mostly realtime optimizations and some drop manipulations) from other runs, and the only really difficult part was Kraid because of the drop requirements. It's about 40 seconds faster in realtime (~13 ingame) compared to Saturn's GT code run despite Bizhawk losing probably a few hundred frames of realtime thanks both to skipping Hi-jump and optimizing lag/doors. Guess I'll hold off here to see how the total control stuff pans out.
So I did some testing on 0xdfe-0xe01 and either I'm thinking all wrong or it'll be hard to make a jump to 4218 with this.
Since 0xdfe-0xdff is all the pressed buttons last frame, and 0xe00-0xe01 is the newly pressed buttons last frame, to make a jump then you need to make 0xdfe to 4C, 5C or 82 by adding 42 or 34 (in case of BRL (82)) to a value. The issue though as I see it is that if we've already used a bit for the first value, we can't use it again when adding, since that button won't be newly held down.
So in the case of wanting to do a JMP (4C 18 42), to get this you'd want to have 0xdfe be A (1010) and add 42 (1000010) to it, but that wouldn't work since bit 2 is already held down from A. The same issue seems to hold true for the other jumps.
So for this to work, the destination address high byte bits would have to be a subset of 4C, 5C or 82 already, so for example a jump to 4018 would work fine.
I hope I'm missing something major here though and this won't be an issue :)
total: I agree. I had thought of 0xe00 as the changed buttons, not the newly held ones. Had it been the former, we would have had full freedom there, but as it is, the on-bits of 0xe00 must be a subset of the on-bits in 0xdfe, as you say.
This is a major blow for this strategy. It eliminates JSR addr (20), JSR long (22), JMP addr (4C), JMP long (5C) and BRL (82). There is sill some hope left for the more fickle JSR (addr,x) (FC), JMP (addr) (6C), JMP (addr,x) (7C) and JMP [addr] (DC). These all work by reading a value from the address indicated, and then interpreting that value as the address to which to jump. Since we can freely control the low byte, and have 6 out of 8 controllable bits in the high byte of that address, we can cover 1/4 of the bank 7e memory, for a total of 16384 memory locations. The probability that the word 0x4218, 0x4219, 0x421a, 0x421b, 0x421c, 0x421d or 0x421e can be found there is pretty good.
Edit: I just made a script for searching ram for these numbers, and I didn't find much. In most rooms in red brinstar the perfect values are always in reachable memory, but other than that the hits were mostly in OAM, where we already knew they could occur. The value can also be formed using the scroll values in 0xb4 and neighbors, and in 0x914. But basically all of these are scroll/position-based, which plays very poorly with the position-based prerequisite for doing anything using the uncharged murder beam in the first place. So I'm currently much less enthusiastic about this approach.
We should probably focus on the OAM or 0b00 strategy of the charged space-time beam instead. For the OAM method, the golden pirates a few rooms right of the GT room are the best candidates. They produce third-byte equals 42 quite often, and no OOB is required. However, it might not be easy to get their x position right. But the best method is probably the 0b00 method.
Yeah it's too bad that the murder beam method seems like it's not going to work in a practical way here since it would have saved quite a bit of time. I searched through ROM bank 90 as well since that's the bank we're in when we enter 0xdc2, and there's no 421x value we could use there either.
I'll try to see if there's any way to optimize the 0b00-method a bit more during the weekend, might be better spots or ways to go OOB that creates less lag and spawns you a bit closer to the right position.
I'm not familiar with the pause glitch. Is there any example of it working? Would it just allow Samus to travel through the heat areas wasting less health?
I'm not familiar with the pause glitch. Is there any example of it working? Would it just allow Samus to travel through the heat areas wasting less health?
The pause menu slowly fades in and out. During the fading animation, you can still move samus for a while, but the game won't go to the "Game Over" screen until the fading animation is finished.
So you can stay at 0 energy forever as long as you keep fading in and out of the menu. Since your energy cannot go below 0, you're basically invincible for as long as you want, and all you need to do is to eventually gain 1 energy back.
The downside is of course that all that menu fading is tedious and boring and wastes a lot of realtime, especially if you want to use it from entering norfair until reaching GT.
If you keep pausing on the first frame possible all the time Samus will survive with 0 HP, and can run through heated areas/damage boost with no health. Though you still can't do something like walljump on spikes because you'll still get the "taking damage" animation.
EDIT: Also the game will be paused for 110 frames and move forward ~60-61 frames between every pause, so it's very slow. I think in this run health should last till about the pre lava dive room before the pause abuse would start to take place.
So, in this case it could have been used for in-game time purposes in the current 100% run instead of refilling in the bug pipe before speed booster, right? It would just look very bad, of course. Glad it wasn't used.
I think it would have been slower ingame because it would have made the pipe bug drops take longer because you'd only get health drops from the first round. I would have avoided using it either way though, seems like a pretty sensible speed/entertainment tradeoff.
I made a quick test run of this using cpadolfs latest WIP as a base and using the charged spacetime and 0xb00 (oob positioning) method. I had to convert the movie to lsnes since Bizhawk doesn't support entering the extra controller bits needed.
It's not at all optimized and just made pretty much as a test to make sure everything works together on a bsnes-based emulator. It uses 5178 frames (about 86 seconds) after entering GT's room until last input to play credits, but I'm quite sure this can be brought down a bit with good optimization.
I also made a very quick and barely functional port of PJBoy's OOB viewer to lsnes so I could navigate OOB to get to the right position.
LSMV file:
http://tas.speedga.me/supermetroid_lsnes_test.lsmv
LUA script:
http://tas.speedga.me/Super%2520Hitbox2%20lsnes.lua
EDIT:
I did some further thinking and I managed to optimize the inputs for ending the game down to 3 frames by overwriting a pointer in RAM and making the game call the controller registers every frame for me. This gives me a lot more controllable bytes per frame since we don't have to setup a loop, and can just return normally back into the game every frame.
I've updated the lsmv file with the new version.
Nice! That's pretty quick still even though the extra supers have to be collected, and it should be improvable by a decent amount as well. Also, is the only goal in the room after GT to reach a certain position, or does something else have to be done as well?
BTW, bsnes does not emulate reading controller registers in middle of poll correctly (alternate poll timings are better, but still not fully accurate).
Oh, and the effects that occur on real hardware pretty much make executing anything off those registers while polling impossible.
Because of this, avoid executing anything off those during scanlines 225-228.
If in controller registers, those scanlines should happen in some state that does not execute normally. At least the following do so:
- Interrupt wait (WAI).[1]
- NMI (invoked at start of scanline 225)
- Active DMA.
[1] If NMI is on, NMI will interrupt the wait, but the normal execution won't resume until the NMI returns.
EDIT: Also the game will be paused for 110 frames and move forward ~60-61 frames between every pause, so it's very slow. I think in this run health should last till about the pre lava dive room before the pause abuse would start to take place.
Hmm.. you take about 10 energy of heat damage per second, which means that saving 100 energy ~ 600 frames of gameplay ~ 1100 frames ~ 18 seconds of pause menu. I'm glad the 6 second item jingle for an additional e-tank is shorter.
