Emulator

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.)

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.

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.

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.

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.