On Sun, Jun 29, 2014 at 6:00 PM, Tomas Abrahamsson <[email protected]> wrote:

            Hmm, crap... I just discovered something new that I do not like.

            http://dehacked.2y.net/microstorage.php/info/1045787175/Test%201.fm2
            http://dehacked.2y.net/microstorage.php/info/48076136/Test%202.fm2

            These videos both start at the same save state, they get the card on the same frame and the full black screen occurs on the same frame as well.

            However... Test 1 is three frames faster due to shorter screen transition. Why?!?!?!?

            It has to do with the way the card is grabbed. But I really have no clue why. This could mean that we have finsihed many levels "incorrectly" and lost a lot of time, and places where we could have gotten better RNG too probably.

            So yeah, let's figure out how the game works =P.


---------------------------------------------------------------------------------------------------------------------------------

    On Sun, Jun 29, 2014 at 10:50 PM, Tom Seufert <[email protected]> wrote:

        Look on the bright side...anything unexplained like this could save time in the accursed warps run!

        This behavior is very bizarre and I'm not sure what to make of it.  When your two movies go black, on the same frame, there are only 2 mem addresses that aren't identical:
        1.  0x1FC - obsolete part of the stack, basically indicating the last thing that was done before the frame ended
        2.  0x74d - x subpixel

        Changing one or both to the other movie's values has no effect; that's not surprising for the stack value since it's an indication of something previously executed rather than a value that is going to be used.  I might be able to use that to dig into the code, but it'll take some work.

        I tried hexing Mario's x position (0x90) on the frame immediately after card is grabbed, and found it would change the behavior:
        x after card obtained:
        134 - good
        133 - bad
        132 - bad
        131 - good
        130 - good
        129 - bad
        128 - bad
        127 - bad
        126 - good
        125 - good
        124 - bad
        123 - bad
        122 - good
        121 - bad
        120 - bad
        119 - bad
        118 - good

        However, this table isn't all that useful b/c getting the above positions by playing the game didn't give the same results.  Also, x-position alone definitely isn't the entire story as from your savestate, you can hold right for one frame (while holding A+B the rest) and get the bad result, but holding right for two frames gives the good result, despite the exact same x position.  That raises the possibility that it's something odd relating to processor internals.

        This definitely bears further investigation.  I definitely wouldn't be excited about redoing the whole 100% if we find it can save a handful of frames, but it'll be interesting to see what, if anything, useful comes of it.  Even before we know what the exact deal is, we can certainly play around the the card grabs and look for those extra bits of lag, maybe I can write a script to check for it as well.

        Interesting!
        -Tom

---------------------------------------------------------------------------------------------------------------------------------

On Sun, Jun 29, 2014 at 11:35 PM, Tom Seufert <[email protected]> wrote:

    Don't think the different stack value at $1fc is anything significant after all.  I found the relevant code, $96fb and $96fb in PRG30.  The two addresses are just one instruction off in a loop that just waits for the NMI (interrupt that occurs every frame to draw/update stuff), so it being different between 2 savestates indicates...not very much, at most a slight CPU timing issue, but nothing that clarifies the cause.

---------------------------------------------------------------------------------------------------------------------------------

Date: Mon, 30 Jun 2014 11:00:55 -0400

Subject: Re: 100%
From: [email protected]
To: [email protected]

I did a trace log to figure out exactly where the 2 movies diverge.  It happens in between lag frames 12 and 13.  In the slow movie, an NMI/interrupt routine gets called in between some PPU/graphics commands and right before a function call that normally waits for the NMI to occur.

This would seem to confirm that it's a CPU timing issue.  In practical terms for us that means avoiding/recreating the delay will be trial and error because there are no predictable/easy ways to cause it for a given level.

Hopefully there's enough consistency in level-transition times that a script can detect this, but for manually looking at it the key seems to be the World Map popping up (or not) the frame after the lag counter stops incrementing.

---------------------------------------------------------------------------------------------------------------------------------


On Mon, Jun 30, 2014 at 4:38 PM, Tomas Abrahamsson <[email protected]> wrote:

Nice research on the matter at least. You sure are better at these kind of things than I am. It's just annoying to find things like this though, as it might complicate things a bit.

But yeah, some kind of script that could determine this would be wonderful. We could also probably count the amount of lag frames before the map screen to know as well. Unless they differ from each time this occurs.

I'll probably slow down a little on my TASing for the upcoming weeks before ESA. As I need to both practice my speedrun a lot as well as planning for the TAS section. It's just nice to TAS a lot when the steam is up, as it has been for the last couple of days :).

---------------------------------------------------------------------------------------------------------------------------------


That sounds good.  I want to put some time in on the total control demo and submission as well.

Unfortunately re: the extra-frames issue, the amount of lag differs somewhat for each particular transition (and I think in theory this could occur for intra-level transitions as well, not just end-of-normal-level-exiting-to-world-map situations).  So not sure if a script will be doable, but I'll give it a go.  But the good news for the 100% (and bad news for the any %) is that in playing through the any %, I didn't detect any cases where such extra lag was present, leading me to believe it's not that common an occurrence.