Emulator Issues #9864
closed
RTC (both using forced override mode and without) does not force the rightmost 5 bits of the generated seed to 0 for GC games
0%
Description
Game Name?
Pokemon Colosseum, Pokemon Channel, basically any GC game that calls dolphin's RTC function to generate a seed (games with the health & safety screen as 1st thing shown have the correct distance between seconds, but lack the forced 5 bits to 0 as well, so they also vary between computers, just to a lesser extent than those without it)
Game ID? (right click the game in the game list, properties, info tab)
GC6E01, GPAP01, others that use RTC seeding
MD5 Hash? (right click the game in the game list, properties, info tab, MD5 Hash: Compute)
pkmn colosseum: e3f389dc5662b9f941769e370195ec90, pkmn channel: b570d1f6ea59c66ceaf8497871b01e88, others
What's the problem? Describe what went wrong.
The RTC seed does not have the rightmost 5 bits forced to be 0. This means there can be variance between seconds in terms of how a game uses the RTC seeding (even for the same game on different seconds) -- it varies by up to 0x00 to 0x1F (5 bits max) from the standard adjustment of +0x40500000 per added second from 1/1/2000 @ 12:00 AM. This means that the RTC seeding function (at least without those 5 bits forced to 0) is inconsistent from any given second to the next, which is a problem for utilizing netplay, TASing, and comparing seeding between two or more computers in general, even when said computers are all using the same dolphin version.
What steps will reproduce the problem?
Boot a game that uses RTC seeding, check RTC seed RAM location once it first calls the RTC function. The seed will most likely have said 5 bits different between two different computers following these instructions. (colo's address for RTC seeding is 0x80478c90, for instance)
Which versions of Dolphin did you test on? Does using an older version of Dolphin solve your issue? If yes, which versions of Dolphin used to work?
5.0-1107, 5.0-1156, 5.0-266, 4.0.2
As far as I'm aware this has yet to be implemented in dolphin, though I could be wrong (it would certainly solve the discrepancies between different computers as far as I am aware, though!)
What are your PC specifications? (CPU, GPU, Operating System, more)
64bit Win 10, i5-2430 @ 2.4GHz
Is there any other relevant information? (e.g. logs, screenshots,
configuration files)
See attached screenshots for a 1-second variance example of 0x4050001a -- one that would be solved by forcing the rightmost 5 bits to 0. those 5 bits seem to vary based upon how fast the user's internal computer clock is. Otherwise, the 0x40500000 advancement is consistent between 1 second and the next. (Tested this on both mine and 2 of my friends' computers -- those 5 bits varied but the rest of the advancing was the same, even when all of us were using the same dolphin version [5.0-1156])
Files
Updated by JosJuice about 8 years ago
So the problem is with the bits that end up in the game's RNG seed, not the bits that are returned by Dolphin's RTC function?
Was your testing done with dual core disabled and g_want_determinism enabled? (g_want_determinism is automatically enabled when using either input recording or netplay, unless you run into issue 9681.)
Updated by Zari01 about 8 years ago
JosJuice wrote:
So the problem is with the bits that end up in the game's RNG seed, not the bits that are returned by Dolphin's RTC function?
Was your testing done with dual core disabled and g_want_determinism enabled? (g_want_determinism is automatically enabled when using either input recording or netplay, unless you run into issue 9681.)
Pretty sure it's somehow related to basing Dolphin's RTC function off the user's computer clock, because this discrepancy is happening across multiple different games, between different RTC values of the same exact game -- on the same computer -- and between the same RTC values on different computers. All of the above would be fixed by forcing those 5 bits to 0, though what exactly that would translate to in terms of the actual RTC function I'm not exactly sure.
Additionally, swapping between dual core enabled and disabled doesn't seem to change the output seed for a given RTC time-to-seed value. Having g_want_determinism enabled DOES seem to change the seed, but only by a variance of something like +-1, and said variance is within that 5 bit boundary as far as I can tell (the 5 bit randomness is also present and consistent with itself beyond the +-1 for a given RTC seeded value when g_want_determinism is enabled).
Hopefully that helps clarify what's going on.
Updated by Fog about 8 years ago
So if I understand correctly, the last five bits of RTC are supposed to be all zeroes? Has there been any hardware tests done to show this?
If not, I'll have to possibly write a hardware test for this.
EDIT: Okay, so the wording is a bit different from what I originally thought.
The hex values being shown in the screenshots are increasing by a decimal value of 40,500,026 or 0x269FB3A every second (Actually, is this every minute? The filenames are showing 12:00 AM and 12:01 AM, unless that is a mis-typed filename for both).
Perhaps it's something to do with how the game is polling the information? I'd need to investigate this further.
Updated by Fog about 8 years ago
Okay, so I got aldelaro5 to take a crack at working out how this RNG seed is getting generated.
ok so I have all info on the colosseum rng, first, it gets called depending on the situation, what needs randomness will roll the rng which is btw a word (32 bits). It can be very frequent battles requests it A LOT (multiple times per frame) or some animations etc...
as for how it's initialised, the first seed is gotten by a call to OSGetTime (it's one of the preincluded symbols within the symbols database of dolphin)
after, the formula is applied to roll it
F(RNG + 1) = ((RNG * 0x343fd) % 100000000) + 0x269EC3
OSGetTime is the following which.....I don;t exactly know what these instructions are lol
OSGetTime
800a2778: mftbu r3
800a277c: mftbl r4
800a2780: mftbu r5
800a2784: cmpw r3, r5
800a2788: bne+ ->0x800A2778
800a278c: blr
r4 is goign to be the first seed if this returns
The problem seems to occur when OSGetTime is called. We're still not sure what's going on with this.
Another problem is that this can widely vary across different CPU cores (JIT, Interpreter, etc.)
This problem is very complicated, and will need a lot of research to attempt to resolve.
Updated by Fog about 8 years ago
- File template.dol template.dol added
I created a simple homebrew test to show the issue. It calls gettick() and gettime() (libogc functions) and displays the results on screen.
Updated by Zari01 over 6 years ago
I managed to isolate where this bug stems from: https://github.com/dolphin-emu/dolphin/pull/3601
That pull (for dev version 4.0-9154) is what is causing the inaccuracies (verified with dolphin bisect tool + runasdate 1.36 for builds without the rtc feature).
Unsure whether this issue is something that should be kept + modified into something like a new feature (does it still have use for VC n64 games?), but at least we know the cause for why this inaccuracy appeared lol.
Updated by JMC4789 over 4 years ago
- Status changed from Accepted to Invalid
This was determined to be incorrect through testing on console.
While Pokemon Colosseum no longer has nice numbers, we can't determine whether or not that's actually correct or not. Given that Dolphin's old model was so imprecise, it makes sense why the old builds resulted in such even numbers. By adding more precision, code that gets executed before the RNG function runs affects the RNG seed which as far as we can tell, is not a bug.
It's possible that in a cycle accurate emulator, things would all even out and the 40.5 million rule would be true, but on console and on old builds setting bios time, that simply cannot be proven at this time.
If I'm misunderstanding something, feel free to leave a note and I'll gladly investigate this further, but after three days of investigation, testing on console with a USB Gecko, and banging my head against a wall while bothering several CPU devs, I'm almost certain the core of this issue report is incorrect.