We removed those 2 delay frames. But apparently there was a miscount of frames? Or was there a delay frame I missed? I noted we're at 7/8 delay at the door. Took a different route just before door to save the remaining regular frames, of which we needed only 1 of the 4 we got from the route, but it hits us with 3 lag frames.
So, aside from retrying boss, what else can we do at this point?
EDIT:
No need for save platform now.
Had a moment of inspiration when thinking about the door.
There's a lot of constraints when it comes to touching the door optimally.
Our dash hitbox is pretty wide, and if we're anywhere further right relative to camera than X 80, the scrolling has to get by an extra pixel, which is enough to delay the door animation, and that is on a 4-frame rule. So being on ScrX81 means the door takes 4 more frames than being at ScrX80.
Of course, being at ScrX80 isn't enough. We're dashing 3 pixels at a time. On the frame we touch the door, we can be 1, 2, or 3 pixels inside the door hitbox. Anything less than 3, and that means the screen takes an extra frame in exactly the same fashion as a sub-optimal camera position of 81, and that one frame translates to four, as above.
In addition, touching the door also hits this same frame rule. As it turns out, our non-platform route was just barely early enough in touching the door on the good side of the animation frame rule. Unfortunately, we were a pixel short. We were inside the door by 2 pixels, not three. The usual plan of walking a frame or two to fix our pixel alignment fails here, due to the fact we lose an animation frame rule on touching the door.
So, we lose a frame rule because we are one pixel short, or we lose a frame rule because we are one frame late.
There was one detail that annoyed me. Running my scripts, I saw that, when scaling the wall under the save platform, we actually had one pixel gap in our ascent. Since we're one frame short of meeting the dialog rule, and fixing the door rule would give us four frames, I would see if sacrificing frames here to align ourselves work. Yes, it gives us a pixel, but at an unforgivable cost! We're far enough left that the camera stopped following us, and we're now in an odd X position. Motion in the air moves us in steps of two pixels, and therefore we can't stop at ScrX80. So I ended up dashing to the door on ScrX81, eliminating any possible savings.
The door frame rule is a vicious one. It may be every 4th frame it lets us through, but... it's not global. The reason why I've been making delays when the door is out of sight is because the frame rule is based on when it spawns. We ascend by wall jumps at 6 pixels per frame. Is it possible, perhaps, that we just hit a bad Y position?
Yes. We had hit a bad Y position.
I delayed the final wall jump up by two frames. Yes, we scale the wall slower, but this incremental change let me move to the right a frame later, but spawned the door two frames later. This key difference meant that, while I still have that bad pixel position as before, in addition to losing a frame, the door's schedule is delayed two frames, and that means I have the frame I can use to fix it and reach the door just in time.
A sacrifice of two frames for want of a single pixel, for want of an animation frame rule, for want of a dialog frame rule. Door animation frame rules are important.
