Challenge of the Month #21 - Space Mama's Crater bonus challenge

[PluMGMK]

Oops, hadn't realized that. Well, I better go actually count up my time then! Doubt it's better than 1234's!

But now I'm curious. I must go and try to figure out what's actually going on there.

[dr_st]

It's not as inaccurate as one might think at first. Assuming it counts from the moment "Run" disappears (and you can start moving) up until the point that Rayman stops at the finish line, then 1234's run (awesome, BTW!) is approximately 1:28 (whereas the timer displays 1:25).

I just did another attempt on the PC and got to 1:42.54, which is very close to my previous result, and since I was using the same technique - it makes sense. I'll see if I can time it using a stopwatch.

[PluMGMK]

Well, if it's off by a consistent percentage, then we should be able to use it for relative comparisons anyway. I would worry that it might depend on the hardware it's running on though… I still want to investigate it, which I will hopefully get to later today.

[1234]

Unfortunately, it's actually not really consistent. Sometimes it even happens that I get a better in-game time for a worse run and vice versa. The only thing that seems consistent is that the in-game timer always(?) shows a smaller time than it should.
A first idea would be that the checkpoints somehow mess the timer up. Maybe the time somehow gets rounded down at the checkpoints, especially considering there are five checkpoints and the in-game timer was roughly 2s (your run) or 3s (my run) faster than real time (average 2.5s which fits perfectly).
Anyway, let us know what you'll find out, please. Would be definitely interesting.

[Steo]

I didn't know that it was actually so inconsistent. Clearly we can't go by that in game timer then or people would be really mad.

[PluMGMK]

Well, here we go. I wrote a little program in Rust to query the game and figure out what the hell's going on: https://github.com/PluMGMK/walkoflife

Turns out that on average, the game's internal timer only counts 990 milliseconds to the second. And then it sometimes drops to 960, and occasionally does a single jump of 1023. You can see the data in pretty colours in the attached spreadsheet (ODS format), working from the raw data here.

I have no idea if these tendencies would be the same if running on native Windows, or on different hardware, but the numbers feel a bit too systematic for that. I'll have to go and see if I can find the timer's internal code in the EXE, and figure out how it works.

EDIT: I did manage to find the code for the Func_GetDeltaTime function that's used in the Ly races, but figuring out where it's getting its input is another matter

[Steo]

Holy crap, it's really off by this far? It's all over the place. I wonder if the devs even noticed at the time, since the point was supposed to be to complete it as fast as you could.

[PluMGMK]

At least I've figured out why… When figuring out the number of milliseconds elapsed between computations, it first rounds to the nearest frame. Then for some inexplicable reason it stores the number of milliseconds – wait for it – as an integer!

So when the game runs at 60fps:
If there's one computation every frame, then the delta ends up being rounded to 16 ms 16*60 = 960 ms per second
If there's one computation every second frame, then the delta ends up being rounded to 33 ms 33*30 = 990 ms per second
If there's one computation every third frame, then the delta ends up being 50 ms 50*20 = 1000 ms per second – This probably helps explain the occasional cases where it went over 1000 ms…

The "good" news is that if the game could be forced to run at 50 fps, the timer would work perfectly.
At least I think it would – I'm not sure whether or not the value it reads from memory as the "framerate" reflects the actual framerate. If not, the solution is even simpler – just force that memory value to 50 instead of 60!

[Hunchman801]

That's a really interesting find, I had no idea the in-game timer couldn't be trusted. We might want to check that for all future seasons of COTM, I guess.

[PluMGMK]

So anyway, how are we defining the run time for this challenge? The full level time as measured from the video, like 1234 did, or just the time that the game is "supposed" to be measuring, as measured from the video? Whatever we decide, I need to update the title/description of my video

[Steo]

I was thinking just from when you start moving to where you finish the race, but I guess it might make sense to go by the speedrun.com rules for it. Either way, it's going to take analysing it by frames to see what the time is in milliseconds. I guess you're working with 16.7ms or 33.4ms round offs though (considering some videos are probably 30fps), so let's just hope that nobody gets the exact same time as each other.

[PluMGMK]

Actually, come to think of it, if we use the speedrun.com rules, we're taking into account the speed at which contestants can flick through the dialog at the end, which doesn't really seem fair. Maybe we're better off just using the actual race time…

[Hunchman801]

I think it might be best to use the actual race time, yes.

[PluMGMK]

Cool! Looks like my run is 6386 frames then, or 1'46"43.

For the craic, here's a ZIP file containing a patched EXE that actually stores the value properly as a float, along with another spreadsheet showing that it now registers about 1000 ms per second (but still highballs to 1016 ms occasionally for reasons I don't understand). I'm not saying this EXE should be used for the competition, it's just something I did for fun.
(Note: I had to patch at least 30 places in total in the code, and had to fix one game-crashing mistake while testing – there may be more in there! I've only used it to load a saved game and play the Walk of Life – I can't guarantee that trying to do anything else with it won't break your hard drive, burn down your house, or corrupt your save file. Also note that this EXE also contains one of the widescreen patches, and another little patch I did recently, based on code I saw in Ray2Fix, to prevent it from crashing on Alt-Tab.)

[Hunchman801]

How easy would it be to come up with a tool that automatically records the actual race time, thereby doing all the frame counting for us?

[1234]

Nice work, PluM! Thanks for figuring this out. So, their questionable decision to use an integer for the ms count is basically the reason for this inaccuracy; interesting. I wonder what might have prompted them to do that...

Anyway, unless I miscalculated, my time should be 1'28"63.

How easy would it be to come up with a tool that automatically records the actual race time, thereby doing all the frame counting for us?

To automatically count the time for the entire level I used LiveSplit with an autosplitter script. It should be possible to rewrite this script to make the timer only record the race time. It probably shouldn't be too hard to do so, I think.
However, I guess a nice small tool might be even better and easier to use, so if anyone wants to do that instead...

[PluMGMK]

Nice work, PluM!

Thank you!

Thanks for figuring this out. So, their questionable decision to use an integer for the ms count is basically the reason for this inaccuracy; interesting. I wonder what might have prompted them to do that...

I mean, the delta is calculated on a regular basis, as a float, and stored in a global variable, as an integer, then that global variable is used in 29 other places in the game's code. All but one or two of those 29 references immediately convert it back to a float, with the associated loss of precision.

[Steo]

Oh well I suppose the entire idea was the race, I didn't consider it to be a game of button mashing after the race. I guess that moment where you hit the end of the race is a perfect measurement then. Nice work on the mod also, I never actually looked into this enough to realise how inconsistent the game timer actually was.

[Hunchman801]

Here's my entry:



The in-game timer shows 1'37"07, and I don't have any tools handy to get the actual race time, so if anyone could help with that it would be greatly appreciated.

[1234]

Just for fun I've created the autosplitter script I mentioned in my previous post. It should automatically start the timer as soon as you start racing and stop the timer at the end of the race as you stop moving. I did a quick test, and it seemed to work quite accurately (maybe +-1 frame or so). It should also automatically reset the timer when you restart the race (either by reloading the level or by falling down before reaching the first checkpoint). You can find the .asl script in the attachments below, and for those who don't want to set up LiveSplit themselves, the Splits file (lss) and the Layout file (lsl):

If you've never used LiveSplit before, here's a small guide:
- Download LiveSplit (e.g. from here) and the zip file at the bottom
- Extract both, then open LiveSplit.exe (you might need to run it as admin)
- Right click on the timer - Open Splits - From File - Choose the lss file
- Right click on the timer - Open Layout - From File - Choose the lsl file
- Right click on the timer - Edit Layout - Layout Settings - Scriptable Auto Splitter - Browse - Choose asl file - Ok - Ok
- Run the game in windowed mode (e.g. with Ray2Fix), otherwise you won't see the timer (unless you have two screens or so, I guess)
- Enjoy the hopefully working timer

Incidentally, I give no guarantee that it'll work flawlessly (or even at all). So, if you have a perfect race and the timer won't stop, don't blame me. Also note that the timer will only count the time for the actual race and not the whole level, meaning it's not in accordance with the rules on speedrun.com.

The in-game timer shows 1'37"07, and I don't have any tools handy to get the actual race time, so if anyone could help with that it would be greatly appreciated.

Unless I did something wrong, I think your time should be 1'41"13. That puts you to ahead of PluM! gg