TL;DR The in-game timer is now displayed live while running the game, check the resources tab!

Hello all! The in-game time project has been a long time in the making and I am happy to announce what should be the final iteration... a live timer display!

Summary: After honing my shockwave knowledge from the previous in-game time patch, I realized it might be possible to have a constantly updating in-game timer displayed on screen. After some beta testing I pitched the idea to TOMYSSHADOW who was once again happy to help! Below is a "casual" speedrun I did with this live timer, so you can see it in action:

Lazy Technical Details: In many ways, the things going on behind the scenes are simpler than the previous patch, since we already have all the code to calculate the patched in-game time at the end. Basically, we can just use the same math from the original in-game time patch, but now do the full calculation before every frame, updating our time display whenever the time increments. There is also a lot of tinkering that is done to have the camera properly display the time without causing lag, flickering, etc., but these things are totally not necessary to get the gist of the patch, and I would be bad at explaining them :)

Happy running!

TL;DR A .zip with a patched in-game timer has been uploaded to the resources tab

Summary: As many of you know, the in-game timer originally built into this game is unreliable. It was found that laggy computers have faster in-game times, but for a long time we did not know why this was the case. This patch was developed by analyzing the original game code to figure out what makes the timer tick, identifying where this goes wrong, and then patching in modified code to fix the reported time. I had been stumbling around attempting this project for awhile, but the big breakthrough was when I managed to enlist the help of legendary shockwave programmer TOMYSSHADOW who went through everything with me and ultimately implemented the patch. This is actually the same guy who put together the original offline projector that we have been using this whole time!

Technical Details:

Background In order to run the physics in this game, On the Run uses a director xtra called Havok which has a property simTime that keeps track of how long the physics of the game has been active: every frame your car moves, there is a step of physics and the simTime value increments. This simTime property is also what gets used to calculate the in-game time. Normally, this timing method functions perfectly regardless of lag since all users on all computers will drive the same distance for the same number of physics steps, regardless of how often those physics steps occur.

The Problem Case 1 - The first case this timer fails is when sitting at the red light at the beginning of the game. During this phase, the game steps the physics according to the framerate of the game, but the time the light turns green is dependent on the change in the system time of your computer. Therefore, if your game is running at 15 fps, you will only have 45 physics steps in the 3 seconds before the light turns green while if your game is running at 30 fps you will have 90 physics steps in those same 3 seconds. In this case, the physics-based in-game timer would register only half the passage of time for the 15 fps user, giving them an advantage. Case 2 - The second case the timer fails is at the very end of the game after crossing the tracks. The run is effectively done once you cross the tracks, but the time doesn't stop here. The physics keeps running, but it is once again disconnected from the speed you are actually moving through the game since the end screen is triggered based on system time. As a result, someone playing at 15 fps will register half the physics steps in the ending sequence when compared to a 30 fps user, once again shaving off time from the in-game timer. There is actually an interesting workaround for this case I discovered while working on this patch. If you hit "P" to pause the game right when crossing the tracks, your in-game timer also pauses since the physics stops, but the game will complete, giving you a much lower in-game time than previously thought possible. This phenomenon can be seen here:

The Patch Step 1 - After figuring out these two cases with TOMYSSHADOW, he immediately began work on a fix. First, he modified the program that steps the physics to include an ability to track if the game was in either of the aforementioned cases. We can tell if the first case is occuring by seeing if the file is on a certain frameScript number, and we can tell we are in the second case by registering the moment the animation for the user crossing the final tracks is tripped. When either case is active, we keep track of the number of physics steps that occur by incrementing an"invalid" physics step counter. The idea is to subtract these invalid steps from the total at the end to give an actual count of the in-game time from green light to crossing the tracks. Step 2 - Finally, we modify the end screen code. Instead of displaying the time dependent on just havok.simTime, we display a time dependent on havok.simTime - invalidSimTime, where invalidSimTime are the physics steps that happened during case 1 or 2 that should not count toward in-game time.

With this patch implemented, the in-game timer effectively starts ticking the moment the light turns green and effectively stops ticking the moment you cross the final tracks. Therefore, runs recorded with this patch will have in-game times that are accurate to the amount of physics-based time the user actually spent controlling the vehicle. As a result, the timer is now completely independent of the framerate you are able to operate the game at.

Notes:

1. The cutscene sequence showing the gates coming up pauses the physics, so we didn't have to implement any kind of fix for that part
2. In-game times recorded with the fixed timer will naturally be lower since they exclude parts the timer is improperly incrementing. Users should make sure to note that runs were performed using the IGT patch, and maybe F1 could adjust the leaderboards to clearly report how runs were conducted

Once again, shoutouts to TOMYSSHADOW since there is no way I would have been able to implement this fix on my own. Happy running!

So in the hopes of tackling the IGT issue I did my best to investigate the runner.dcr file. I was somewhat successful, and made a few simple modifications to the game:

-Invulnerability -Increased fuel capacity -Items in different locations -All areas loaded at once (allows for a neat shortcut) -New text on end screen

Unfortunately, I was unable to see how the IGT worked at all, so it is likely buried in byte code that is indecipherable for me. Below is a """"speedrun"""" I did on my hacked game to showcase these changes.