That seems like a very unusual (and large) way to produce a pseudorandom sequence. Why not a linear congruential generator or LFSR? They have approximately the same state storage requirements, but much less static data.
Doom was probably squeezing every last cycle out of 386 @ 25 MHz machines to render frames, but they did have at least 4MB–8MB RAM; 256 bytes seems a good trade-off.
I presume that speed was the determining factor, not saving bytes.
This may also present the advantage of being tweakable to avoid repeated sequences that better generator may naturally produce but are not perceived as 'random enough' by humans.
Comments
That seems like a very unusual (and large) way to produce a pseudorandom sequence. Why not a linear congruential generator or LFSR? They have approximately the same state storage requirements, but much less static data.
Presumably they were optimizing for CPU cycles rather than RAM, and the 256 bytes that it does consume isn't much in the scheme of a game like Doom.
This must be pretty fast (and compact) code: rndindex = (rndindex+1)&0xff; return rndtable[rndindex];
The example C code at https://en.wikipedia.org/wiki/Linear_feedback_shift_register looks like it would compile to more bytes, and require more CPU cycles to execute.
Based on https://en.wikipedia.org/wiki/Linear_congruential_generator it seems LCGs also micro-optimize for memory rather than CPU performance.
Doom was probably squeezing every last cycle out of 386 @ 25 MHz machines to render frames, but they did have at least 4MB–8MB RAM; 256 bytes seems a good trade-off.
I presume that speed was the determining factor, not saving bytes.
This may also present the advantage of being tweakable to avoid repeated sequences that better generator may naturally produce but are not perceived as 'random enough' by humans.