EDIT: TheXTech 1.3.4 will adjust the framerate and introduce the same in-game timer that is used in SMBX2, as well as 3 Speedrunner Modes. Mode 2 simulates SMBX2 Physics, Mode 3 simulates SMBX 1.3 Physics. 1.3 will use RTA timing. —————————————————————————————————————
After I submitted my AllStars% Playthrough, concerns were raised about the viability of TheXTech for speedruns. Therefore, I'd like to start a discussion about new rules to ensure a fair, inclusive and comprehensive leaderboard.
The ideas I want to propose are:
- Only allow whitelisted SMBX Versions and add a Filter for them in the Leaderboards.
- Whitelist 1.3, Beta 4 (SR Edition), and TheXTech with FPS Limiter.
- Display both, the Time without Loads and Time with Loads.
- Ban leaving the episode through any means (including Game Overs).
The fourth point is important for both, SMBX2 (as it's In-Game Timer doesn't account for time spent in the menu) and TheXTech (as Players spawn at the entrance of the last level played when re-entering an Episode with Hubworld).
TheXTech, for those who haven't heard, is an open-source C++ Port of the Original SMBX Code, with Accuracy to 1.3 being a declared goal of the project. It can be used by MacOS users and Linux users with a non-AMD64 architecture who can't run SMBX or SMBX2. It has one downside: The Framerate is inconsistent, being about ~67 on Linux and ~66 when ran via Wine. As such, it runs faster than SMBX2:
https://video.ploud.fr/videos/watch/d42cd157-98fa-49c0-9310-38f6d137f524
This issue can be resolved with a Frame Limiter. According to Valtteri, SMBX has a framerate of "64.1025 641025 641025...". On Linux, I installed LibStrangle and ran TheXTech with the following command:
strangle 64.1025 /path/to/thextech -m -p
-m enables the FPS Counter, while -p prevents the game from freezing when losing focus. The result:
https://video.ploud.fr/videos/watch/7e8a964a-b208-4754-a8fc-6aa2621efb49
TheXTech Players can and should be required to use a Frame Limiter and display the FPS Counter.
Hopefully an approach like this will add clarity and make SMBX a more popular speedgame.
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
Hi Wohlstand, happy you joined the discussion :)
Before the timer is made, it should be first cleared up how to approach Menu Quits. I see three possibilities:
- Menu Quits are banned. Personally, I don't like this, but it would be the easiest option for consistency between all three versions.
- Menu Quits are allowed and counted. TheXTech can consider this in it's timer, SMBX2 Users would have to calculate the difference manually.
- Menu Quits are allowed and not counted. In this case, runners should be required not to spend more than 5-10 seconds at once in the menu.
In both cases where Menu Quits are allowed, TheXTech would have to add a Compatibility Feature for Hubworld spawns.
1.3 Users are only relevant on Windows, so they can use LiveSplit to ignore Loading and Menu times.
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.
Wohlstand: Okay, just now I had to tune the framerate controller and seems it works now as intended.
The first thing I noticed is that the "Speeddemon" Cheat Code is broken. Otherwise, it looks fine:
I also tried to record the Windows Version via Wine, but unfortunately couldn't find a way that allows me to control both at once =/
Wohlstand: P.S. Even the original SMBX built on VB6 will give the same 67 FPS result on Wine.
Can confirm! 
I guess that gives enough reason to ban using 1.3 via Wine.
Wohlstand: TheXTech is older than 1.3.4 required to use the framerate limiter.
If Menu Quits are allowed, older versions of TheXTech will have to be banned, as being spawned at the level entrance gives Players a huge advantage:
Streamable - PeerTube (Transcoding)
Eclipsed: There's too many runs at this part that don't have them included, that recalculating them will become a logistical nightmare.
I don't think that New Rules should affect old runs in any way. It is common policy in several leaderboards (GTA5, CTR) that runs are valid as long as they followed the rules at the time of submission. So even if Menu Time will be counted from now on, it can be required for future runs only.
I'm totally fine with it not being counted though. Out of the solutions I listed above, the third one is my favorite.
Eclipsed: For menu quits, we should ban anything that saves time
I disagree. Allowing Menu Quits unless it is advantageous is a way to guarantee legal grey areas. What if a Menu Quit didn't mean to save time, but happened to do so? I'd rather deal with simple rules that go against my preferences than with unclear or complicated ones.
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
- Ban menu quits which hamper the progressions of strategies in the game
- 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.
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.
I see. If it's just that, it's simple enough I think.
Then people on Xtech would spawn right next to the level.
Wohlstand already added the Compatibility Feature to fix this:
https://github.com/Wohlstand/TheXTech/commit/773f3651d85c10b06fd6e83ae663460142e64fef
https://github.com/Wohlstand/TheXTech/commit/aa70b6a8651d24a9f76c5a425f29abcc6c985be3
I tested it yesterday and it works, so that's no longer an issue.
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
I know, hence my idea to require Runners not to spend more than 5-10 seconds at once in the Menu. With the rules as they are now, they could take an hour long break in the menu and their run would still be technically viable. I'd like to have that loophole closed.
So, if a rule like this is made:
Menu Quits are allowed, but you may not change characters in the Menu, and you may not stay in the Menu longer than 5 seconds.
I think it will be fine.
Could you make/send me your discord userID since it takes way too long for forum posts to get a response.
I avoid closed-source messengers. XMPP is the fastest way to reach me. I can also offer Jitsi Meet (requires no registration) if you want to talk at a specific time.
I don't think that's necessary though, as I pretty much reached the limit of what I can contribute to this discussion. The next step would be for you and Mech to let Wohlstand know what he needs to consider for the Timer and the Speedrunner Mode.
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, I check my Twitch Messages at least once a day.
The first two lines of the Menu Quit Rules sound good!
The third line I think is unnecessary, as it will be included in the Speedrunner Mode, so you can just require TheXTech users to use that (either Mode 2 or Mode 3).
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
Awesome! ^-^
The Game Timer appears to work the same way as it does on SMBX2. On Game Overs, Quits, and Save Quits, the time is saved.
The Level Timer however doesn't stop when reaching an Exit: https://imgur.com/a/zA0Kqfk
