The prime factorization of $110D83 (1117571) is 7 x 13 x 12281, so it's perfectly fine as a mod(224
) 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(2n
) 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