As more and more extreme luck manipulation happens (the Monopoly video is brought to mind), I can't help but wonder if the randomness that games have works the same way on the console and on the emulator.
Can we be sure that the emulator and the console compute random numbers in the same way? If not, is this an inevitable problem, or something that can be fixed? Do you think this is even important? I'd like to see your perspectives on this.
Can we be sure that the emulator and the console compute random numbers in the same way?
It is the game which calculates the random numbers, not the emulator.
However, the game calculates them with mechanisms that are subject to emulation artifacts.
For example, in Rockman 1, the random counter is updated on every frame (by a part of the game code which is executed on every NMI) -- even when it lags. However, the occurances of lag depend highly on the emulator (the number of cycles it emulates per frame, and the penalties it incurs for memory accesses, etc), and because of the lag, it may be that you reach the situation at a later or earlier frame than on the real console, and thus, getting a different random value, even if you outputted precisely the same sequence of input.
(This is btw why movies are not portable across emulators.)
Other games might use even more volatile measures to influence the randomness, such as the horizontal scanning position of the PPU. I know of no game that does that, though.
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
Aside from what Bisqwit said, I don't think it's a real problem. Emulators are usually coded such a way to mimic the exact behaviour of a console. However the software computes it's random number (consoles don't provide this, except perhaps the current generation consoles), the emulator has no direct say in the matter.
As for the behaviour of the games I played on the console and the ones on the emulator go, they feel the same. I'm sure anyone else will say the same. So I don't think it's an important matter, as long as the moviefiles work ;)
NES executes an interrupt function (NMI) 60 times per second, every time the screen refreshes.
Normally, the main program of the code will do certain calculations for each frame, and then wait for an NMI to occur, and then do the same calculations again, for the new frame, etc, ad infinitum.
However, the CPU can only execute a certain amount of work between each interrupt, and if it happens that the CPU hasn't yet finished calculating all the work for the current frame when an NMI happens, it means that the work for that same frame will continue the next frame, and only when it's finished calculating that work, it'll wait for another NMI to occur, before starting a new frame.
The game is experiencing "lag" if an NMI occurs before the main program has returned into a NMI-waiting loop.
Other systems also work in a similar manner. There are exceptions; not all games have a main loop -- SMB1, for example, does all of its work inside the NMI. I haven't analyzed those in detail.
Isn't the NMI 60 times per second in an NTSC NES and 50 in a PAL NES? This is, AFAIK, because the internal clock is calibrated with the AC power supply which in NTSC countries is 60 Hz and in PAL countries is 50 Hz. (I wonder if there are any NTSC countries with a 50 Hz power distribution or viceversa. If there are, I wonder how NTSC/PAL works there...)
As for the lag, one has to remember that the CPU in the NES is pretty slow (especially compared to current PCs and game consoles which are supercomputers in comparison) and it just isn't fast enough sometimes to do all the calculations in time for the next screen refresh. That's actually the reason why there are so many glitches in NES games and much fewer in SNES games: In the latter there's much more CPU power to check for glitchy conditions while in the NES they have to do some shortcuts sometimes and just hope that the player doesn't find the glitches.
By the way, doesn't that mean that with 50 Hz games, the CPU has more "time" to process the data between the interrupt call; thus, there potentially is less lag in them?
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
Yes, but the game just runs inheritantly slower (unless the prorgammers compensated by accelerating physics, gravity, etc). And lagging isn't all that common except under periods of high stress. This is why PAL games on SDA tend to be longer than their NTSC counterparts.
There are some games that just can't run without lag (Shatterhand for a recent example). I thought it could be useful to know with other games like that.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
