Potential Methods for Universal Loadless Timing
7 years ago
United States

Loadless timings are currently usually done in one of three ways, all of which can only work in a few specific scenarios.

  1. The game is a PC game and has an autosplitter that removes loads by checking memory addresses. Obviously, this won't work for console.
  2. A flat conversion is used- say console X takes 5 minutes of loading total, while console Y takes 7. You'd take the final times and subtract the amount of loads by console. This works alright for, say, Crash 4, but loads can vary between models of the same console, or even different playthroughs on the exact same console! This also only works when all runs have the same amount of load screens- some games will have different routes, or mistakes that add a load. (for example, Spyro EtD has a load after a death) Therefore, this method only works for some games, but when it does work, it works well.
  3. Runs are timed RTA and then the video of the run is manually gone through to remove loads. This works with very high accuracy on every game, but also takes by far the most effort of these three methods as EVERY run will need to be retimed, as opposed to only timing one or two runs.

None of these solutions are ideal and I've thought about this conundrum a fair amount, and I think I've come up with two possible solutions that essentially automate option 3.

The first of these methods would be a program that takes a video of a run and automatically removes the loads, outputting a new video file with the loads removed. This has a potential issue of removing parts of gameplay that are actually loads, but image matching algorithms could be loaded with "this is a load". I'm envisioning inputting a list of images (or better, videos, but this would make implementation harder) that show what loads are (in the case of images, start and stop points) and having similar frames be removed. This probably wouldn't work too well, but was the first idea I had that showed some potential.

The second method, and the one I believe would actually work for 99% of games, is a cross between methods 1 and 3 above, using the idea behind the universal load remover. This could be an add-on to LiveSplit or a separate running program that just counts how long the run has spent on loads. It would rely on image matching again: I'm envisioning a UI that would allow the user to define a load as: ¤ A start point. This would just be an image file, and the user would be able to specify certain portions of the screen to look at. ¤ An end point. Same as above. ¤ An offset. Many games wouldn't allow finding the exact start or endpoint of a load, but this could be worked around by counting how many frames early or late the comparison frame is, and adding this value to the load time for a given load. For example, in Spyro games level loads start with a fadeout. This can start from anywhere in a level, from entering a portal or pausing and selecting "Exit Level". This fadeout has fixed time, and would be the offset before the consistent animation. ¤ Optionally, a similarity. If the load would look similar to gameplay, the user could specify that it needs to be 95+% similar to count as a match. If the angling can be different, then perhaps only a 30 or 40% match would count. ¤ The same method could potentially be used for universal autosplitting. This could be run either live, comparing to a preview window, or on a finished run, allowing easy retroactive retiming.

There are two main downsides to this idea: the first is the obvious one, that every load would need to be manually configured. However, this would only need to be done once, and it's slightly more work than retiming one run for method 3 above, and the definition of a "load" can be standardized by the community for each load. The other downside is almost as obvious: this hypothetical program would be a fairly complex technical challenge. I'd do it myself, but I don't have the technical know-how. But I have the idea and have been mentally tweaking the specifics of it for a couple years now, just never really shared it. It came up on the Sprash discord today and I figured I should post the idea in case someone wants to try to work on it or refine the idea.

So: any thoughts?

Here's my proposed solutions for PC specifically. Tried to format it nice so your eyes don't get spammed.

Universal Load Time Remover Application (ULTRA) I think a better option would be to make a program that can hook the Windows API and detect any file reads. This could be a simpler task than one might think.

This program would inject some code into a process. The code creates an internal timer. This timer can be start and stop by the user (or perhaps a user-defined plugin can start and stop it automatically). When the API for file reads is triggered, this would signal the timer to stop (needs to be very low latency). When the file read is over, we can signal the timer to continue.

Although this will exclude load times from the HDD, it cannot exclude any processing time on that data. This is an even bigger issue for a lot of games.

Some problems with this idea:

  1. Multi-threaded applications. This could potentially introduce some unpredictability in how and when the timer will stop exactly.
  2. Asynchronous load times. Some games continue to run even while loading a file. This means if you have slower load times, you will gain an advantage. (For example, you are able to move for more frames while a load is occuring).
  3. File streaming. Particularly popular among old games that have movies or music. Sometimes the data from the storage device is received as a constant stream, and the game will continue the run. This has similar issues to asynchronous load times.

All of these problems have to do with parallel processing. We could prevent 1 and 2 with a "stop the world" mindset. Halt all execution of the program (and the timer) until the load is complete. This would be a problematic approach for some games.

PC / Load Time "Emulator" Another solution would be to make a sort of emulator that can time the game in frames or CPU cycles, and emulate load times as 1 cycle or frame (instant loads). Problem? It's too resource intensive to run a full blown virtual machine. Even a "Windows" emulator would have to emulate x86 (a complex processor), co-processors, and the entire Windows API (or treat Windows DLLs like BIOS files, which would then lead to non-uniformity). That also comes attached with potential legal issues. Perhaps there's an area between native execution and emulator that would make this solution viable, but I don't see it.

(Workaround) Fast File Driver My WORKAROUND-TYPE solution would be to make a driver that creates a virtual drive where you can store all of the data in the game. The actual physical location of this data would be on some fast memory chip (such as RAM). This eliminates hard drive speed variable and moves this limitation to how fast your RAM is, as well as your CPU cache lines. The obvious problem with this solution is that not everyone has huge RAM space to store entire games (let alone did Windows OS eat it up?). And this only narrows the problem by shrinking the range between one person's load times compared to another.

Conclusion The root cause of the "unfairness" of speed runs comes from the fact that PC hardware is not standard. Everyone has hardware that operates at different speeds and magnitudes. The "catch-all" solution would be an emulator, but that's a huge task to take up.

With all these in mind, I'm still pro RTA in many ways. What is faster is faster. Load times consume time. A speed run's purpose is to finish the game as fast as possible. Either you run in an optimal environment or you can't compete RTA. That's the unfortunate truth with speed running. Consoles help standardize this a bit, but you still have to worry about model, version, firmware, system/disc health, etc. There's also very few games where their IGT is completely fair. Even if you write load removers, some less obvious load times can be missed.

However, if anyone who understands the technical workings and issues with my proposed solutions, I would be happy to work on such a project.

Edited by the author 7 years ago
England

It's a good idea, but is harder to universalise than you think. The idea of image matching loading screens doesn't work for any game that goes to any lengths to mask the loading times, such as Metroid Prime. That problem where a door doesn't open for ages after you've shot it? That's because the game is loading the room behind the door; the time between shooting the door and it actually opening is in and of itself a loading time.

It's an odd example perhaps since the game doesn't hang or display a loading screen per se, but there is nontheless loading going on, and I imagine other games will have their own ways of doing this.