Detect real-time ingame

[Leseratte10]

hello everyone,

Is there any way the emulated game / application can find out the speed it is running at? Like, can the game find out that it is only running at 90% speed because the computer is too slow or because the user set a frame limit?

I tried reading the time registers (mftb and mftbu), but it looks like these return the time based on the emulated speed, not the real time based on 100% speed.

Is there a way a game can know the actual system time, so it can compare that to the emulated time, so it can know how much time was lost due to a slow emulation?
Or do I have to use workarounds like requesting the current time from a server so I can use that to keep track of real time?

[JosJuice]

We intentionally try to not let the game know the actual speed it's running at, since we want to avoid any odd side effects that games might present if they are run with unusual timing. There is one big way in which we leak timing information from the host system, and that is the difference in performance between the CPU thread and GPU thread when using dual core (and this does cause problems in some situations, like F-Zero GX's tendency to reset), but I don't think this is of any use for what you want to do. Requesting the time from a server is probably the best way to go if you want to know the actual time.

[mstreurman]

We intentionally try to not let the game know the actual speed it's running at, since we want to avoid any odd side effects that games might present if they are run with unusual timing. There is one big way in which we leak timing information from the host system, and that is the difference in performance between the CPU thread and GPU thread when using dual core (and this does cause problems in some situations, like F-Zero GX's tendency to reset), but I don't think this is of any use for what you want to do. Requesting the time from a server is probably the best way to go if you want to know the actual time.

Wouldn't doing this get many issues with games like Pokemon that track the time and invalidate the saves if it thinks the savefiles have been tampered with?

hello everyone,

Is there any way the emulated game / application can find out the speed it is running at? Like, can the game find out that it is only running at 90% speed because the computer is too slow or because the user set a frame limit?

I tried reading the time registers (mftb and mftbu), but it looks like these return the time based on the emulated speed, not the real time based on 100% speed.

Is there a way a game can know the actual system time, so it can compare that to the emulated time, so it can know how much time was lost due to a slow emulation?
Or do I have to use workarounds like requesting the current time from a server so I can use that to keep track of real time?

I'm wondering why you would want to do that? So one could fake more speedruns? So that speedruns could be done on lesser hardware and the speedrunner could just slow down the game and say: hey I lost 50 minutes because the game was slowed down, but all is good because I know exactly how much time I lost because of this, please mark my record as new world record?

Sorry for being so cynical but that is the only reason I could think of why one would want to do that... and I do NOT support that at all...

[JosJuice]

Wouldn't doing this get many issues with games like Pokemon that track the time and invalidate the saves if it thinks the savefiles have been tampered with?

I don't see how this could cause any problems with that.

[mstreurman]

I don't see how this could cause any problems with that.

Game ran slower thus the time in game is less than real-world time... Games sees at saving: hey, it is 10.15am, but that is impossible because according to my calculations it's 10.10am, the save must be tampered with... invalidates save, you lose all your progress...

[JosJuice]

Game ran slower thus the time in game is less than real-world time... Games sees at saving: hey, it is 10.15am, but that is impossible because according to my calculations it's 10.10am, the save must be tampered with... invalidates save, you lose all your progress...

But the game doesn't know what the real-world time is – that is the core of what we're discussing in this thread. When it tries to check what the real-world time is, Dolphin will say 10.10am, even though it is 10.15am.

I'm wondering why you would want to do that? So one could fake more speedruns? So that speedruns could be done on lesser hardware and the speedrunner could just slow down the game and say: hey I lost 50 minutes because the game was slowed down, but all is good because I know exactly how much time I lost because of this, please mark my record as new world record?

Sorry for being so cynical but that is the only reason I could think of why one would want to do that... and I do NOT support that at all...

Since they're working on Wiimmfi, maybe they're looking for some way to detect which players are running the game too slowly. People who do that can gain unfair advantages over others, depending on how the game is coded.

[Shonumi]

But the game doesn't know what the real-world time is – that is the core of what we're discussing in this thread. When it tries to check what the real-world time is, Dolphin will say 10.10am, even though it is 10.15am.

Can't games just read from the GC/Wii RTC and figure out any discrepancies? If you track the number of times you hit VBlank or hardware timers, you could calculate time manually, and then compare that to the RTC (which should be based on the host system time).

Unless, is Dolphin doing something weird with the RTC? E.g. doing something like using the host time as a base and manually adding the appropriate amount of time for each frame? Usually you'd just ping the host time whenever RTC registered are read, so doing it any other way seems odd, but I can still see the reasoning behind it.

[JosJuice]

Unless, is Dolphin doing something weird with the RTC? E.g. doing something like using the host time as a base and manually adding the appropriate amount of time for each frame?

Yes, that is essentially what Dolphin is doing (except more often than once per frame).

[Shonumi]

Yeah, I guess the read/ping method is good enough for simpler systems where RTCs were uncommon, but probably doesn't cut it for later gens with save checks like mstreurman pointed out.

I suppose another workaround would be the GBA-GCN connection instead of a time server. Theoretically speaking of course, since it's not well-emulated, but there would be all kinds of ways to leak the host system time if you're dealing with homebrew or hacks (and a second emulator which Dolphin has no control over).

[Leseratte10]

@mstreurman I'm not trying to cheat in any speedruns. It is exactly as @JosJuice said, when games like Mario Kart Wii run too slowly in Dolphin it causes problems (the slow player has advantages in the game), and we'd like to work against that using a patch, but we'd need to know how much the game slowed down to do that. And @Shonumi, the emulated RTC is indeed actually emulated by Dolphin and doesn't return the host's RTC, so it'll run slowed down as well.

We could just have the server send a time / timer to Dolphin, but that would be far less accurate (due to network transmission / ping) than having a way in Dolphin to get exact time / lag information.

Maybe it'd be possible to create some kind of interface in Dolphin which can be used by Dolphin-aware homebrew / code to get some information that isn't normally exposed to the game? Like a /dev/dolphin (functioning like /dev/es) that could have ioctls to get the real system ticks, the current Dolphin version, the amount of frames Dolphin is "behind" realtime or other stuff about Dolphin that could be useful for homebrew / custom code to know.