I guess I know how to solve this: the world map does call of gfx update at the start (on SMBX2, this means, affects the timer in one tick), and I should call the timer tick at a beginning of the loop, lemme try...

EDIT: no, I do call of GFX update at me to trigger the initial lazy-decompression of gfx at the level start. Anyway, please compare the total game timers from the entire passthrough at zero-begin, and up to enter the next level, will total timers match or have the difference?

@Wohlstand, did you make an update to the build? @0hli, in the meantime can you get the IL WRs for A Short Level Fake Exit

Downloaded the latest build and Xtech is still one frame faster

Downloaded the latest build and Xtech is still one frame faster

You better compare the global timer at the level start, make next:

• add the "end game" event in "Level - Start" of the level1 to stop the timer at the final moment (for SMBX2 it seems you need to also make the "Boss Dead" event because it can't just hook the native "end of game" event, TheXTech does native hook of that event to stop the global timer) And try in both games accurately. On my side, I do get different results on the same engine randomly because the result depends on how fast I'll hit the JUMP key when a player reaches the LEVEL1 point.

So, I do get the 0.5.491 of global timer or slightly bigger value in other times. I sent my unit test to 0lhi to verify on SMBX2.

@0hli the SMBX2 timer doesn't use the Native End Game Event, SMBX2 uses the Boss Dead event to stop the timer. Don't forget to submit your record to the IL borad.

I'll be back later.

About the reason why extra time displayed at SMBX2 after the world map is the reason "GameThing()" (an inter-screen with a character face and lives left) wasn't rendered over the last frame, instead, the rendering of SMBX2' inter-screen was started in the next frame. That means the time itself has counted accurately. Therefore I do ask to verify the total time of "complete episode playthrough" to take the proper time being counted.

The last question is left - the keyhole exit: at SMBX2 it was majorly customized and no idea how it keeps the FPS of it: the main thing that the keyhole exit code is bad at SMBX 1.3, and instead to work in the same logic, it starts to work by 100 FPS (you'll see that blocks and BGO go with a faster animation once player touched the keyhole). I fixed that shit by adding the common framerate controller and by converting waiting values from 1/100 into 1/65 to keep the same gap waiting. So, I should try to verify the behavior at SMBX2 against the timer and keyhole exit.

BTW, one small update I made at TheXTech - I fixed the inability to save speed-run records once the game got completed, a very minor fix of a very major issue. So, once you'll beat the game and once credits start, together with an automatic game save, the speed-run records will be also saved.

About the keyhole, I confirm that SMBX2 still has the badness of SMBX 1.3 that runs the keyhole waiting with 100 FPS, and this is Redigit's block of code that runs a keyhole: https://github.com/smbx/smbx-legacy-source/blob/master/modMain.bas#L6624-L6644 In comparison, the normal framerate controller of a level running: https://github.com/smbx/smbx-legacy-source/blob/master/modMain.bas#L1780-L1822 the big and dirty block of FPS controller, Redigit has to put it multiple times rather than making a united module with using of function pointers. Blocks like this do run the game with ~65 FPS. Keyhole block runs 100 FPS instead. That problem makes the lua-based stopwatch count the timer faster as 1.5 fast-forward running than normal playthrough. That distorts the total time counting completely.

How keyhole waiting timer counts the time: https://imgur.com/hQSo00C , pay attention to the animation speed of BGOs and block rendering. Keyhole at TheXTech: https://imgur.com/EH73RL7, the animation and time counting goes the same as regular level playthrough. All SMBX 1.3, SMBX2, and TheXTech do 3 seconds waiting between key touching and the level exit.

EDIT: The video https://imgur.com/EW67H3k

I'm confused, why does Xtech and SMBX2 report the same End Episode Time, if their world map times are different?

@0lhi, I can confirm that is indeed the case @Wohlstand, the world map is way faster on Xtech than on SMBX2, for building tiles

I'm including the frame that didn't appear in my calculations SMBX2: 0.811ms, 1.294ms XTech: 0.811ms, 0.55ms

In the second case, XTech isn't calculating the time properly at all. I looked at the approximate RTA time and it was around 1.233s (Give or take a few frames)

Last 3 Things to Verify: World Map Build Time Keyhole Time Trigger Timer Stop on Specified Event Name (Or Create Level Files that Do it Earlier for Cliche/Invasion 2)

@Wohlstand, is it possible to have the timer for Xtech end at a specific event name or does it have to be at "Game End"

@0lhi it's the same video

The XTech is way faster on the world map when new tiles start appearing.

I need to compose another unit test to check this more detail... I may guess that it's one of not patched at SMBX2 code pieces to don't 100% overload CPU. Graphically it may go slower, but it does the SAME cycle count: between every cell appear step, there are 24 frames wait constantly.

@Wohlstand I was inaccurate, it's not faster. It's just not calculating properly. In Real Time, it's ~1.23 seconds, and in Xtech it's displaying 0.530 seconds.

Two Level World Map Test: https://files.catbox.moe/hblec4.zip

is it possible to have the timer for Xtech end at a specific event name or does it have to be at "Game End"

It's possible to introduce the keyword to trigger the speedrun timer to finish the counting easily, mainly if you want to stop the timer to count without the game being completed. Mainly the "Game End" event is intended to be a way to stop the timer. I can use the same "Boss Dead" as a codename for the event, or it's also possible to have other keywords as aliases: the event will work by its normal, but will stop the stopwatch to count.

In Real Time, it's ~1.23 seconds, and in Xtech it's displaying 0.530 seconds.

blame Redigit's code on how the path-opening code is processing.