3 ms·

I am curious what went wrong during development here. Was it an accident? Did someone think that it would be a waste to throw away all these fine higher bits

I am curious what went wrong during development here. Was it an accident? Did someone think that it would be a waste to throw away all these fine higher bits and just did anything with them? (It feels a bit like a self-designed crypto algorithm when someone adds complexity because that's sure better than not, isn't it?) They might not have been too familiar with linear congruential generators (LCG) because then they would have known that casting the result to an unsigned 32bit integer was not an accident but the modulus operation of the LCG (here: "mod 2^32"). See [0] for details. [0] https://en.wikipedia.org/wiki/Linear_congruential_generator https://en.wikipedia.org/wiki/Linear_congruential_generator

no_multitudes 5y ago
I wonder if it could have been done to shut up some static analysis tool?
- bentcorner 5y ago
  That's my guess too. They were probably using ranqd1, then someone turned on a new warning, then someone else had to figure out what to do with the warning without really understanding the change they were making. It'd be interesting to see if the same randomizer is used in other SMB games after NSMB and any ports.
  - _Microft 5y ago
    I don't think this would make a warning go away. value + (value >> 32) is still a 64bit int value that gets then cast to a 32bit int.
    - bentcorner 5y ago
      Whoops, good point. Uh.. maybe there's a cast in the original source and the bit shift was added at the same time?
blackboxlogic 5y ago
Speculating: Perhaps a feature for automated regression testing? Start the game with the "cursed" seed, run your script of inputs and compare the outputs against the results of your last production release. Versus the normal RNG, where a game difference which touches the RNG would alter ALL following output, hiding later game differences.
- flatiron 5y ago
  my thought exactly, its a feature not a bug. a way for a unit test to possibly "play" the game with RNG effectively "disabled"
- pcwalton 5y ago
  That's far too subtle. If a developer were going to add a debugging mode like that, they'd just add a flag that's checked in the function and makes it return a constant.
  - _Microft 5y ago
    That was my thought as well. Why bother with finding a fix point of your PRNG (and messing up its properties in the process) when one could use something like #ifdef ... return 4; instead.
- xyzzyz 5y ago
  It would be much, much simpler and much more robust to just have a flag that when set, makes RNG returns the same number, instead of depending on some very obscure behavior of specific hard coded constants chosen.
tinus_hn 5y ago
This was probably implemented in assembler, which makes it easy to make a mistake like this, and how are you going to check?
- pcwalton 5y ago
  I doubt this was implemented in assembler. It's not performance critical, and 32-bit ARM is a friendly enough target for a compiler that a human won't be able to improve upon the compiler's output anyway.
- NobodyNada 5y ago
  Assembler? That seems very unlikely, as this was a DS game released in 2006. Ever since the Nintendo 64 and GameBoy Advance, compilers have been good enough and the hardware has been more than powerful enough that games have been typically implemented in C.

no_multitudes 5y ago

I wonder if it could have been done to shut up some static analysis tool?

bentcorner 5y ago
That's my guess too. They were probably using ranqd1, then someone turned on a new warning, then someone else had to figure out what to do with the warning without really understanding the change they were making. It'd be interesting to see if the same randomizer is used in other SMB games after NSMB and any ports.
- _Microft 5y ago
  I don't think this would make a warning go away. value + (value >> 32) is still a 64bit int value that gets then cast to a 32bit int.
  - bentcorner 5y ago
    Whoops, good point. Uh.. maybe there's a cast in the original source and the bit shift was added at the same time?

blackboxlogic 5y ago

Speculating: Perhaps a feature for automated regression testing? Start the game with the "cursed" seed, run your script of inputs and compare the outputs against the results of your last production release. Versus the normal RNG, where a game difference which touches the RNG would alter ALL following output, hiding later game differences.

flatiron 5y ago
my thought exactly, its a feature not a bug. a way for a unit test to possibly "play" the game with RNG effectively "disabled"
pcwalton 5y ago
That's far too subtle. If a developer were going to add a debugging mode like that, they'd just add a flag that's checked in the function and makes it return a constant.
- _Microft 5y ago
  That was my thought as well. Why bother with finding a fix point of your PRNG (and messing up its properties in the process) when one could use something like #ifdef ... return 4; instead.
xyzzyz 5y ago
It would be much, much simpler and much more robust to just have a flag that when set, makes RNG returns the same number, instead of depending on some very obscure behavior of specific hard coded constants chosen.

tinus_hn 5y ago

This was probably implemented in assembler, which makes it easy to make a mistake like this, and how are you going to check?

pcwalton 5y ago
I doubt this was implemented in assembler. It's not performance critical, and 32-bit ARM is a friendly enough target for a compiler that a human won't be able to improve upon the compiler's output anyway.
NobodyNada 5y ago
Assembler? That seems very unlikely, as this was a DS game released in 2006. Ever since the Nintendo 64 and GameBoy Advance, compilers have been good enough and the hardware has been more than powerful enough that games have been typically implemented in C.