SMBX physics datasheet?

[Olepa]

I was wondering, considering that quite a few people in here must be working on extensions and remakes of SMBX, someone might have already created some kind of a reference datasheet for physics and controls-related things like acceleration and gravity and max speed constants etc from the reverse-engineered code, so maybe someone already has something like this that I could use for reference? I don't know if there's a common name for these but something kind of like that datasheet for SMB1 by Jdaster64 (this one btw provides not only the raw values but, for example, explains some things about the movement such as the exact way mid-air or swimming movement works)

I've been making (mostly for educational purposes for now) a simple platformer game project in another game engine, and, credit where it's due, I really admire the smoothness of SMBX's physics and controls, it's probably my favourite fangame in this regard

So I was thinking of implementing a faithful recreation but, well, measuring out everything myself seems to be quite a pain, however, again, I believe someone might already have information like that

[Wohlstand]

Hello!

SMBX physics can be easily investigated through the source code. Just keep in a mind, that game treats 65 ticks as one second (but real-time is slightly slower). The rest of physics values were specified here https://github.com/TheXTech/TheXTech/blob/main/src/main/setup_physics.cpp and here are a lot of related initial variables values were set here: https://github.com/TheXTech/TheXTech/blob/main/src/main/setup_vars.cpp

[Olepa]

Well, I guess this makes sense, to look in the source code… althogh I kinda didn't expect it to be in just a single code file, and I was also surprised though that all the values are just dumped like that in a single code file, but I guess it probably was how Redigit did this too lol

Just keep in a mind, that game treats 65 ticks as one second (but real-time is slightly slower)

Okay, I understand, but what does this clarification "(but real-time is slightly slower)" mean? Is it a significant and perceptible change or would the actual in-game FPS still be closer to 65? Like, it says in the first link that the player's terminal velocity (vertical) is 12 (apparently in-engine pixels (with 32 px per tile) per tick), would it be fine to just multiply by 65 to get the per-second value?

Also I don't think I've managed to find values for acceleration and friction in there, and these are for now the only ones that I had troubles with — a sheet from another guy I've replied to before, it included the values for acceleration and friction but after I converted them they seemed too unrealistic for me and definitely not SMBX-like: for example, the running acceleration was 5 times higher than the walking acceleration yet the max running speed was only two times larger, so the player would just accelerate to max running speed super quickly; meanwhile for some reason the regular deceleraion was much higher than skidding, making the player just come to a very abrupt stop

[Wohlstand]

(but real-time is slightly slower)" mean

It's because internal treating of one second is different from real-live time counting, with a minor difference.