You can see an obvious manifestation of this in the attract mode of Contra which plays back a pre-recorded stream of button input and relies on determinism to replay the demo exactly the same each time. That means that even if two emulators implement the logic of the CPU instructions perfectly, they will still generate different random sequences if their timing is not exact. One consequence of this approach is that the particular sequence of random numbers you’ll get is heavily dependent on the exact cycle level operation of the CPU and the interaction between the CPU and the video hardware. Instead, the next random value is generated by spinning in a tight loop during the time that the game is idle and waiting for the next display frame to begin (while waiting for the vblank interrupt.) During that time, the game continually adds the current frame counter value into the random number over and over again until the video hardware in the NES signals to the game that it’s time to begin processing for the next display frame. The way that it updates the random value each frame is kind of interesting in that it doesn’t implement any particular algorithm that you can call on once per frame to get the next number in the sequence. I’ll start off with a table of contents for this series for easy reference and then dive into the last few details.Ĭontra has a single global 8-bit value that it uses as the source of randomness throughout the game. Some of these things are details of the game’s programming and some are just interesting things about the game itself that I never knew before.
CONTRA NES COVER COMPARISONS FULL
To round out my discussion of Contra I’m going to cover a few miscellaneous topics that don’t warrant a full writeup on their own.