Which randomizer to use?

[hackfresh]

This game creates 3 "random" single numbers. Each one is updated AT LEAST once per frame. Sometimes there are subroutines that re-update the randoms mid frame. Basically the randoms are generated by adding prime numbers to each other. This has he problem of looping every 256 frames.

Is it me or it doesn't clear the carry between additions? That would be basically doing a 24-bit addition then. I guess that means that the 3D byte will go the longest without looping???

Ahh good point. I guess for the main routine that occurs every frame you are correct it is doing 24 bit addition!

The game does call these individual routines at times where it updates the single bytes.

Code: Select all

update_random_3B:
	LDA RANDOM_3B
	CLC
	ADC #$83
	STA RANDOM_3B
	RTS

update_random_3C:
	LDA RANDOM_3C
	CLC
	ADC #$0D
	STA RANDOM_3C
	RTS

update_random_3D:
	LDA RANDOM_3D
	CLC
	ADC #$11
	STA RANDOM_3D
	RTS

[rainwarrior]

The prime factorization of $110D83 (1117571) is 7 x 13 x 12281, so it's perfectly fine as a mod(2²⁴) cycle of additions. I would expect this to have slightly better behaviour than 3 independent 8-bit cycles.

Super Mario 3 actually ticks its random number generator once per frame, and anything that needs a random number that frame just samples it. Pretty similar to what you're doing there. It seems like this method could lead to bad things like two of the same enemies onscreen moving in lock-step with each other, but it's probably easy to avoid if you're careful. (Or maybe that's the kind of bug that is "fun" to have?)

I actually use mod(2ⁿ) addition cycles like that for lots of things in my game. I do OAM cycling by picking a different additive factor each frame and cycling through my objects to draw in that order. In this case, though, I am not looking for "random" as much as I am looking for "different order each frame". Sort of a different concern than a PRNG, because I want it to predictably cycle through a well behaved set of orderings.

The big reason there's so many different PRNG code samples out there is that for a lot of purposes there's a really low bar for "random". If you just need something that seems uncorrelated you can do some really trivial / quick stuff that works fine in the context it gets used. (Example: Yars' Revenge just uses the game's ROM as "random" looking background data, because it was quicker/easier than generating it, I guess.) The problems usually come from expecting a random generator that works fine for a very limited application to work everywhere. Producing a generic PRNG that is suitable for wide usage takes a bit more theory and testing. It's not uncommon for "bad" PRNG code to get copied to a lot of places because it seemed fine in most cases and nobody really tested it thoroughly. Example RANDU.

[Sik]

Super Mario 3 actually ticks its random number generator once per frame, and anything that needs a random number that frame just samples it. Pretty similar to what you're doing there. It seems like this method could lead to bad things like two of the same enemies onscreen moving in lock-step with each other, but it's probably easy to avoid if you're careful. (Or maybe that's the kind of bug that is "fun" to have?)

Actually, enemies going in lock-step is probably more useful than harmful...