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 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.

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.

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?

Btw, In the morning I received your archive with a second unit test, no idea how to properly test it, and what it's the goal? Can you explain what to do with the unit test and what result is's need to take?

Eclipsed

Mode 2 has been extended: https://github.com/Wohlstand/TheXTech/commit/dd9cce59fe4ecb347efa48a972f6a62d46fe38f3

If possible, could you post the test files you used on the github? This would be the quickest way to approve the timer

Which one? 0lhi's unit-test that counts a time? Or levels used by me to record those GIFs? Yeah, I can easily give the pack of them in one set (I'll make the "test" subdirectory at my TheXTech repo where I'll put those files)

2. The Github Documentation Page About Glitches https://github.com/Wohlstand/TheXTech/wiki/compat.ini---Tune-the-compatibility

For convenience, just now I made the GIF demo for each compat.ini flag when it's true or false, in total 26 GIFs for 13 existing options. Find GIF links on the page.

There's an issue on windows where the framerate on WIndows is consistently on 200 for the newest XTech build so I can't do more tests

Fixed just now, that was a mistake in the Windows version of the frame rate controller that wasn't tested properly. I debugged it on my second machine, and I completely fixed it. At me it got 300 fps, heh. By the fact, because of the mistake the 'MaxFPS' started to work without that flag being set

Right now, I'm trying to get my discord back so I can more quickly contact with Wohl about this situation.

Alternatively, you can try to use XMPP way, 0lhi can explain to you everything easier

Okay, the true reason for the manual-run bug was the miss-counting of the first frame. I also found that my Android version had returned me the 18.860. However, I had to tune the gameplay timer code: I removed the unnecessary saving of the current level time into the game save file, and I had to start the frames counting from 0 rather than 1. That had to completely fix the issue, and my recent Android run makes the 18.844 pass.

Make it so that in speedrun mode, all levels have autorun turned on. The "autorun" is an event, and its purpose to seize the player's controls and make the player walk automatically. The problem 0lhi explains is the fact controls were not handled at the first frame, and the player had to start the walk with one frame later. The problem is only at level begin, it doesn't affect all other times of the level. So, I should be sure that the manual-hold 0lhi's unit test will pass the check with the same result as SMBX2.

One frame of loss each level can make a huge difference throughout a whole run. I'll try to check the controller handling to fix this issue, probably tomorrow, as today at me is too late time I will need to sleep.

TheXTech: 18.860 seconds It's the difference of one frame at the beginning if you have to just hold the key at your controller. For the fair test, you should use the autorun and keyhole by the event (I sent you an example of you at XMPP). I received your level and tested it when I added the autorun event with held RIGHT and RUN keys, and the game has shown the same result in 18.844 as SMBX2.

The Level Timer however doesn't stop when reaching an Exit Fixed!

have a M1, M2 or M3 at the top-right corner Added!

Feel free to get the latest dev build and test the result.

The Level Timer however doesn't stop when reaching an Exit: https://imgur.com/a/zA0Kqfk

The bug, the only one question: should I stop the level timer when the player dies?

Wohlstand: Would it be possible to have a M1, M2 or M3 at the top-right corner to indicate which Speedrun-Mode is being used?

Easily!

Just now I finished my work on the speed-running mode, so, the next dev build will have it being on a board!

How to enable the speed-running mode: https://github.com/Wohlstand/TheXTech/wiki/Command-line-arguments#speed-running-mode

Btw, about the "speedrunner" mode I gonna make, I have the next idea:

Give three options of the speed-run mode, all of them will enable the built-in timer to count how long you play the level and/or episode:

• Mode 1 - common X-Tech mode: keep mainstream features, use this to play TheXTech exclusive episodes (which originally targeted to TheXTech itself and using its features)

And two modes if you want to make the speed-run for episodes originally played on the vanilla SMBX 1.3 games:

• Mode 2 - Vanilla SMBX 1.3 behavior except for some bugs (disable any time-winner features like the "last warp hub resume")
• Mode 3 - Strict SMBX 1.3 behavior, enable all bugs and disable all gameplay improvements, let a player have the pain

So, if you play speed-runs in Mode 1, they all will have "TheXTech speedruns" and will not fit into "SMBX 1.3 speedruns" because of specific differences.

Here is the full list of compat.ini features: https://github.com/Wohlstand/TheXTech/wiki/compat.ini---Tune-the-compatibility

If needed some bugs to be re-enabled for Mode 2, please tell me, I'll count this.

The first thing I noticed is that the "Speeddemon" Cheat Code is broken

Fixed just now, that was a regression bug, caused by the forgotten "MaxFPS" state checking

as being spawned at the level entrance gives Players a huge advantage

This is a feature for the casual playthrough that avoids the huge pain when resuming the game. For the speedruns case, I added the "compat.ini" option that disables this feature, and the player gets to start the hub from the scratch on a game resume. Simply put the "compat.ini" at the episode with the next content:

[compatibility]
enable-last-warp-hub-resume = false

So, there is will be the next requirement for TheXTech:

• TheXTech 1.3.4 and newer.
• TheXTech is older than 1.3.4 required to use the framerate limiter.