arx/ArxLibertatis — comment on commit 64817c18fdfd305e80890a924cc0853ba3965f63
File:  line 0
By adejr:

I'm really not sure why that would have fixed the problem.

One solution to avoid the variable definition of rand() is to generate the numbers directly rather than using a call to rand().

float random_float() {
static uint32 nz = 0xB160BEEF;
nz *= 0x000343FD;
nz += 0x00269EC3;
return float(nz>>16 & 0x7FFF) * (1.0f / 32767.0f);
}

This provides the same result regardless of the system it's executed on. For higher precision you would need to combine multiple results after the shift and mask. For example, float((nz1>>16 & 0x7FFF) | (nz2>>1 & 0x3FFF8000)) * (1.0f / 1073741823.0f)

The scaling change does seem backwards from what would have fixed the range issue. I suppose it's based upon the idea that MAX_RAND would be defined as 32768 when the real value was as in the function above.

Whatever the reasoning for the change it appears to have fixed the issue when it was implemented. If there hadn't been an issue I wonder why the change would ever have been made.

I should have detailed that in the commit log. We did discuss the issue in the IRC channel.