The main issue is we might not have the technology to support these differences. Also, we need to talk to Wohlstand for the timer

Hi there! Thanks to Eclipsed and to MECHDRAGON777 who linked me to this discussion, so, gonna answer to given questions:

• Regarding the accuracy of the framerate, I made this issue: https://github.com/Wohlstand/TheXTech/issues/27 The framerate code in TheXTech right now is equal to the code of SMBX, however, this isn't optimal, and that gives some challenges with it, including the bad work with some levels on slow computers such as my Archos 70c tablet (where I tested my WIP Android build of the game).
• Do you want me to add the playthrough timer that will count the time since the episode begins? I have two ideas on this: -- add the real-time counter that will watch for the system clock -- add the physics cycles counter that will count time by counting of in-game physics cycles counting every cycle as 1/65 of a second. The note that loading scenes will don't increment this timer as that part doesn't draw anything but loads the stuff at the back. But, it will count the time while staying at the world map and levels.

Right now you can have the same framerate if you will enable the v-sync renderer (will not work on some video cards or when you have no drivers for it), however, the game would work slower if 60 Hz is set up. EDIT: use "-r vsync" to tell the game to use the V-Sync based renderer

About the time counter, I made this issue, feel free to post any suggestions/notes/tips: https://github.com/Wohlstand/TheXTech/issues/34

Anyway, the time "64.1025" is not so proper, so, to get this delay in as-is form, I get the:

• 1000 / 64.1025 = 15,6000156 milliseconds delay
• 15,6000156 milliseconds = 15600015,6 nanoseconds On Linux I have the "nanosleep()" call that allows staying this delay approximately and the std::chrono API that allows to getting nanoseconds too. So, the question of what actual inter-frame delay is getting be counted? Or, just round the inter-frame delay into 15.6 milliseconds (15600 microseconds)

P.S. I see some of the code here https://gitlab.com/torkel104/libstrangle/-/blob/master/src/limiter.c, tomorrow I'll try to adapt it and make it do the proper work.

Okay, just now I had to tune the framerate controller and seems it works now as intended. I reviewed the way how the Strangle keeps the framerate, and I made a similar code that does its work. I also had to tune the Windows code because of UNIX-specific nanosleep functionality which on Windows is a pain. I need to let anybody verify the result on Linux and on Windows. Once this build will finish, you can try any of the dev builds: https://github.com/Wohlstand/TheXTech/actions/runs/537340135

P.S. Even the original SMBX built on VB6 will give the same 67 FPS result on Wine.

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.

Hey 0hli, regarding menu quits, they should not be included in the in game timer. There's too many runs at this part that don't have them included, that recalculating them will become a logistical nightmare.

Basically on Xtech and SMBX2, according to Wohlstand one tick should travel the same amount of distance in both version. Will need to test this more, so theoretically Xtech can use the same in-game logic that SMBX2 uses for the same in-game time if a level is optimally ran.

Also, allowing for menu quits allows for an easier time for newer runners, and menu quits rarely saves time and it's best to just restrict the two cases where menu quits could theoretically save time.

For menu quits, we should ban anything that saves time, you cannot use the main menu specifically to change characters. Menu quits also should be banned from leaving a level or quick travel in a hub world.

Other than that, menu quits make you lose time since you have to replay a level again.

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

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.

0hli, there's only two possible ways that menu quits can save time, and as long as people abide by avoiding those, it should be fine. There's literally no other way for menu quits to save time.

For episodes with world map, menu quits ALMOST NEVER save time. You're always required to rerun the previous level so every menu quit adds time. The only issue is that we should prevent menu quits specifically to change characters for world maps. I can guarantee you this is the only thing that saves time for world maps and was planning to ban it originally.

For hubworlds, menu quits are a bigger issue. The reason for this is that let's say that you're doing a run with two levels back to each other. The first level is optimal with Toad and the second level you can save two minutes if you switch to Peach. Now, what if the episode allows you to play Peach and the only way to access it is to switch characters via menu. Then people on Xtech would spawn right next to the level.

So either in this case

1. Ban menu quits which hamper the progressions of strategies in the game
2. Ban XTech which I don't want to do or 3. Have XTech runners use specifically mode 2 for runs. In this case since both (in-game timers for SMBX2 and XTech don't account for menus and I'm pretty sure is probably impossible to do), both version are on equal ground.

In essence, menu quits only help Xtech runners. Since in both SMBX2 and XTech the (in-game timer does not account for menuing). The other issue is that lua code does not run on the main menu, so including menu time it's virtually impossible to capture an accurate time if we include that, since SMBX runs at >60 fps that frames will be skipped in video. So if two runs are five frames apart, then it's possible the person behind 5 frames on the leaderboard actually has the world record and this is something that I want to avoid.

Could you make/send me your discord userID since it takes way too long for forum posts to get a response.

Yeah so does this sound good?

Menu Quit Rules: Runners should not spend more than 5-10 seconds on the menu For World Maps, Menu Quits Should Not Be Used to Change Characters For Hub Worlds, XTech Runners are Required to Use (No Last Warp Hub Resume Mode)

Do you check your twitch messages?

The last thing I need to do is run a series of tests of comparing the In-Game Timers

Yeah the third line in your statement was what I said, I just phrased it differently.

Now I just need to run a series of tests between the two timers to ensure that it's equal.

Yeah the third line in your statement was what I said, I just phrased it differently.

Now I just need to run a series of tests between the two timers to ensure that it's equal.

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