User Files from FatRatKnight

f30081 *** STAGE 4 ***
f30313 Segment 0: 232
f32030 Segment 1:1717 (T4:1741 . T3:1745)
f32294 Segment 2: 264 (T4: 245 . T3: 264)
f32439 Segment 3: 145 (T4: 152 . T3: 155)

Well, saved 13 frames before the miniboss. Discounting that, taking the Team 3 route through the miniboss has us dropping three frames for animation stuff to sync miniboss. Assuming we didn't need that delay, and the miniboss follow-up with that save platform can't be done with Team 4's miniboss strat, our net is Seg1:-14 Seg2:+19 Seg3:-7, or -2 frames. The difference is razor thin. I would advise myself to look a little deeper here.

Changed when I took damage from some fish. I noticed I was delaying just before a wall. So I took damage earlier, so when it came to those spikes, I would lose invincibility sooner and get more damage from there. In turn, because I took damage earlier, I didn't travel as far, and therefore no longer delay at a wall.

Ghost Fall has a good ammo drop at the moment. Further improvements might lose that. We'll see what comes if I continue.

f30961 - 6 frames ahead of Team 4 (x1733, flame charge timer at 2) f31813 - 4 frames ahead (lost 2 frames) (x3861)

The x values I'm using are the white numbers from my script, which is the player camera offset plus the camera position. The cyan numbers from my script relate to player position, except they are apparently whatever was last used for terrain collision, and are less "true" to the player's location.

f30450: Injected Team 3's input. Under scrutiny, I spotted that they were stopped for one frame before the flame charge prior to the breakable. I fired the flame charge one frame earlier in response, for a frame.

f30600: Following Team 4 right after, I was crashing into some nasty lag. Changed strat for flame shot at offending sub. I can change shot timing to refill ammo (+3), but I also get one lag frame.

f30800: Decided to delay jump as long as possible.

f30961: Chosen moment of checking optimizations (1733 by white number). Team 4's run is 6 frames slower to this point.

f31340: Pause refill advanced to this timing. Previously around f31580.

f31813: Another chosen moment of checking optimizations. x3861 by white number, x3885 by cyan number. My 6 frame advantage shrunk to 4 frames.

I left the remainder of the movie in after that moment, but I don't expect full sync.

Ammo is lower at this point, but at least we're synced up on animation frame rule with Team 4. Difficult to tell where changes need to be made between the two teams for the miniboss, so I'm leaving this for now. From what lapogne36 reported, Team 3 was two frames faster between my last frame check and the ladder ahead.

Nothing to report, Stage 4 is identical to Team 4's run. Curiously, whatever changed in prior stages, it all lined up the 32-frame rule and item drops happen exactly as before.

This is in case no one wants to mess around with trying to copy in some team's run. Team 4 is the fastest, though not by a wide margin, and there may be some strategies to mix in from others. I'll make a more detailed post thinking about each team's efforts soon.

Another version of the External Radar script.

The only real difference this time is sticking the map data into a global variable instead of a local one, and handling it as a global that might already exist before it comes in.

Because ThunderAxe31's brain refuses to acknowledge how the back foot pixel works. It's not your fault, it's your brain's fault.

I threw together the ImportantPlayerPixels function in a hurry and all that. It paints tiny little arrows indicating what pixel the game cares about based on the situation. I advise ThunderAxe31 to examine these arrows in frame advance. Since I threw the function together in a hurry, I can't really guarantee its accuracy.

On a side note, this script now sticks the maps into a global variable, so that, once I upload an update to the ExternalRadar, the two scripts will be aware of a loaded map already done and share the resource instead of having local copies. Shame a core reboot kills the global variables, and a reboot is done every time you switch movies. Perhaps good for stability, but makes it problematic if a script has several seconds loading time.

Oh, right. Someone did have a smart loader that grabs only a smaller portion, the one relevant to where you're at. I should track that down, or design my own, perhaps.

Version 2 is out! Now with fewer errors!
... I sort of used the wrong name for a particular function. Error fixed! Just about the entire version log, really.

So, with 50% fewer known errors (and who knows how many fewer unknown errors), I hope this script can be used and with no need to fiddle with the internals.

Run script, preferably before a few hundred thousand frames passed (running it after that time should quit the script immediately, an error I don't plan to fix without a sufficient reason explained for the fix), then run whatever video capturing stuff you encoders do for TASes. Should remove a total just under 15 and a half minutes of transitions.

I request an encoder takes a look at this script and tries stuff. For use with BizHawk while running (SNES) Push-Over and a TAS of it, and creating a video file of it.

The basic idea is to get rid of screen transitions, and the address I found seems to indicate the moments where the game screen is visible and G.I. Ant can be seen going through doors. I've ran the test function and I can't find any errors in the logic I used, and this address really does look like this magic screen transition detection value.

This script is intended for encoder use. I don't really touch encoding myself, so I'm hoping the script works fine fresh off this page. Might be jarring that it goes straight from G.I. Ant going in one door and immediately the screen's at the other door he's going out of.

Enough explanation. Here's hoping it works as advertised, and all you have to do is run BizHawk, this script, and activate whatever encoding function is necessary to produce some kind of media file.

f23576 *** STAGE 1 ***
f24541 Segment 0: 965
f25125 Segment 1: 584 (T3:583) They probably jumped. Need to check.
f25221 Segment 2:_ 96
f25431 Segment 3: 210
f26191 Segment 4: 760 (T3:758) Interesting. Need to check this out.
f26688 Segment 5: 497
f27502 Segment 6: 814 (T4:822) Despawned a flame
f27742 Segment 7: 240 (T4:236) Frame rule
f29159 Segment 8:1417
=== END OF STAGE 1 (Frames: 5583) ===

Copied Team 4's run. Only real modifications are manipulating different ammo drops and despawning precisely one flame, which saves exactly one frame rule. And, for some reason, a 4 frame delay at the gate, as if we're out of sync of the dialog frame rule by 4 frames. Which is odd, since I don't see any obvious effects from the Stage 7 boss that would change our stage entry here by a multiple other than 8. I will recommend to myself to figure out how the Stage 7 boss ended up different.

Item drop manipulation wasn't too painful, but if we do enter the stage 4 frames earlier, we're going to have to manipulate again. Bah.

f16175 *** STAGE 7 ***
f17129 Segment 0: 954
f17945 Segment 1: 816 (T4:814) Miniboss Skip set-up
f18487 Segment 2: 542 (T4:501) Miniboss Skip set-up
f18675 Segment 3: 188 (T4:106) Miniboss Skip set-up
f18744 Segment 4:_ 69 (T4:236; T7:69) Miniboss Skip
f18952 Segment 5: 208 (T4:206) Lagged
f19344 Segment 6: 392 (T4:407) Positioning after miniboss
f19968 Segment 7: 624
f20158 Segment 8: 190
f20513 Segment 9: 355 (T4:356) Changed block destrction
f20867 Segment10: 354
f22279 Segment11:1412 (T4:1411) Frame rules?
=== END OF STAGE 7 (Frames: 6104) === (T4:6159)

We still have +2 lag following the miniboss, but I did get rid of one lag frame and managed to pull together some ammo without lagging somehow. Also fixed the boss, which did apparently require minor edits to have it work, so not a complete resync.

I blame the array starting at IWRAM:7C44, and object data offsets +0x0E (2 byte) and +0x40 (4 byte), for being a malloc substitute for painting sprite graphics. Due to the fact I destroyed a different enemy for my ammo, this somehow caused 2 lag frames later, which was removed by attacking a lag bomb to delay its self-destruct, and to delay a charge so I omit its graphics for just a little longer and avoid the second lag frame. Nice to see removable lag.

Again, I blame some graphics allocation routine involving those object offsets and the array. Probably scans through from the start of the array and works forward trying to find a large enough open region. And the regions are distributed differently from different enemy destruction, probably extending the search and lagging as a result. Or so I suspect.

f16175 *** STAGE 7 ***
f17129 Segment 0: 954
f17945 Segment 1: 816 (T4:814) Miniboss skip
f18487 Segment 2: 542 (T4:501) Miniboss skip
f18675 Segment 3: 188 (T4:106) Miniboss skip
f18744 Segment 4:_ 69 (T4:236) Miniboss skip
f18952 Segment 5: 208 (T4:206) Positioning?
f19345 Segment 6: 393 (T4:407) Positioning?
f19969 Segment 7: 624
f20159 Segment 8: 190
f20515 Segment 9: 356
f20869 Segment10: 354

Yes, T3 has a faster Segment 6, but they don't set up the invincibility. I haven't double-checked for efficient routing, though.

We are landed sooner than T4 after miniboss, and a little further to the right relative to camera. Generally advantageous, as we can dash sooner, and we can always sacrifice camera relative position if it means a better position to shoot the immediate enemies.

This run falls flat against the boss, though. We have added lag in a few spots, we're low on ammo and no lag-free options I can find, and basically in some mess with the overall sync.

Although the frame rule is always the important thing to keep in mind, removing lag are firm savings. One lag removed is one frame saved, since the game's frame counter doesn't increment in lag, and therefore delays the frame rule by however much we lag. I haven't checked our gate frame rule for frames we can safely sacrifice, however.

On top of not having ammo, the initial damage we take from the boss doesn't sync either. Probably a matter of taking close looks between Team 4 and this run.