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.

I'm having trouble holing out in 2 strokes at hole 11. Ella did it just fine, despite base Drive being 5 yards short of Neil's, thanks to her Height being higher. Of all the irony of selecting Ella for the seriously low Height, Neil's lower Height this early in the run is getting in the way here at this hole.

Uploading this before I forget I have it, mind.

f07477 *** STAGE 8 ***
f08158 Segment 0: 681
f08386 Segment 1: 228
f09189 Segment 2: 803
f09339 Segment 3: 150 (T4:165) Ladder path
f09472 Segment 4: 133 (T4:121) Ladder path
f10262 Segment 5: 790
f10384 Segment 6: 122
f11039 Segment 7: 655 (T4:661) Better capsule path
f11170 Segment 8: 131
f12060 Segment 9: 890 (T4:900) Despawn
f12449 Segment10: 389 (T4:386) ... what?
f12699 Segment11: 250 (T4:246) Door delay for boss sync
f15254 Segment12:2555
=== END OF STAGE 8 (Frames: 7777) ===

4 frames delay at boss gate. This is to sync the boss, and even if we remove this delay, the dialog frame rule gets in the way, and not one frame is saved even if we redo the boss. So the gate delay is an easy sync that doesn't cost time.

Our s8 is now faster than Team 4's s8 by 12 frames. Would be 16 if dialog frame rule wasn't a factor, or we somehow find another 4 frames in intro. Yay ThunderAxe31 for finding an improvement that got me seeking another improvement.

There's probably some obvious mistake I completely missed on Segment 10 or something. Not sure, but we need another 4 frames if we're going to beat the dialog frame rule, though.

f16207 *** STAGE 7 ***
f17161 Segment 0:954
f17977 Segment 1:816
f18516 Segment 2:539
f18707 Segment 3:191
f18776 Segment 4: 69

Something like 5 frames with a different route through that last segment. This might be the winner of the stage 7 miniboss skips.

There may be a minor frame loss in how long it takes to get into position after the miniboss, but certainly less loss than what the new route gains. I can't put myself any further left relative to the camera.

I'm still hoping a frame is saved in Stage 8, before the 3 frames dropped by the ladder after the miniboss. That would save an animation frame rule. That, in turn, will save a dialog frame rule. And that will collapse the 32-frame rule the start of Stage 7 is based on right now (f24 delay at the moment). Mostly, I'd like to be lazy in redoing Stage 7, and I'm being lazy on the pretense there is a frame to save in Stage 8.

Nifty. Thanks Dacicus for figuring out the perimeter bounds.

The corner boxes only apply if you're moving diagonally in that direction. Otherwise, they are inert and spawn points do not react to them.

Hopefully this addition to the script makes it better at dealing with things decidedly off-screen. It was nice being able to see the moment enemies appear before. Now it's ever nicer to know ahead of time when they will, and if it can be avoided with camera trickery.

I've also added commented lines expecting the other three boxes.

If you want to question the fact I have a function (CanvasSpawnBorders) for the rather specific purpose of painting these spawn boxes, then you should also question my decision for making a function that paints exactly one box (CanvasBorder). My decisions are generally based on what information is being handled.

For record keeping, this is how to skip the miniboss in the intro. Shame that setting this up takes more time than just smashing the miniboss.

We also can't Ghost Fall down the next segment. We're not at the right edge of the screen.

Shh... Secrets. Which has no business being secret anyway. Making public any changes once I make them is hardly secret.

Some comments removal (code holdover from the hitboxes script), fixing the enemy coloring (variable name mismatch), and identifying the spawn locations. It will also recolor the spawn spot if it's in use.

The spawns was something I was looking for during the contest, but I didn't find it myself. I suppose I should thank Dacicus (or however the username is typed).

You should be able to create your own save state from this. Or modify the movie to switch weapons on the way to take damage. Or something like that.

Some attempt at analyzing effects of Charge Swap.

Playing around with two possibilities: Sticky Meteors and MurderBarrier.

I choose to die because the Sticky Meteors refuse to leave. Makes showing off the other "charge combo" a bit tricky otherwise.

Here's the infinite climb. He keeps going and going...

There are no boundaries that will stop our hero from climbing. Even when you think he has reached the top, and there's nowhere else to go, he keeps climbing.

Shh... Secrets. Stand-alone script.

This script combines the virtues of both the terrain tiles and the hitboxes scripts, but pastes the info onto a separate canvas. The viewing area is 2x of the game's normal viewing range, so we're seeing half a screen out in each direction past the visual boundaries. It's a heavyweight script, so be aware of slowdowns when running it.

The terrain tiles loading is not aware of the tiles script, so if both are running, there will be two copies of the same data loaded into lua. They are several hundred KB in size, so do be aware.

Shh... Secrets. Script #3, intended to be run third.

Displays a few different stats for each onscreen object, like HP, invincibility timer, and stuff. Top-right has position info, lower-right is our RAM watch dump, and top-left has a few timers in mind. Lower-left gets the object counts for lag reasons, and the bottom is our item drop finder.

Well, it's the basic script. Not a lot to say, really.

Shh... Secrets. Script #2, intended to be run second.

This script is the one with the hitboxes. All of them, player, projectile, enemies, and items. They are color coded, too. Enemies are colored based on HP, with zero or negative given a vastly different color. Player projectile is colored based on whether it does damage, rather important for the Muzzle Flash I'm sure you're all frustrated with by now. This is what the game was doing to detect all those hits. Also nice to know what's happening with the basic projectile when changing weapons.

Oh, and this script has rescaling, with M and N keys, so we can see off-screen enemies. Only problem is the other scripts aren't rescaling, so... Uh, enough embarrassment, and stand in awe of my ROM diving skills. Finding and then following pointers around can be fun.

Shh... Secrets. Script #1, intended to be run first.

This script paints an overlay on the screen, showing what type each tile is, in convenient color coding. This is what we use to know exactly when air ends and walls begin. Seriously, there are spikes that aren't there in Stage 4, walls that aren't there in the sixth stage part of END, and plenty of floor clips that this script makes apparent very quickly. Also be sure to look for backward slopes in the intro and Stage 4, too.

Note that the script takes a few seconds to load all the tiles into lua tables, as this method means I won't have to do several memory reads to get the right pointer, adjust it, then fetch the right tile. The script is much slower in runtime without this loading step. Also, this required some ROM diving, and I had better hope this thing is useful!

Intent of the script is to state how many frames it took to complete the immediate segment, as well as how long it takes to do the stage. The state machine in it insists that it sees the beginning of a stage before it starts doing its counting. Hopefully, this will make comparisons easier. If anyone has ideas on better measurement points, I don't mind suggestions.

I've commented out a piece of code, around line 145, that would report how many frames you spent traveling at each pixel/frame. The script is keeping track, just that it won't print the actual stuff without that stuff I commented out. It's cleaner without it, but if you want the added information, go find that spot.