From: cr88192@gmail.com   
      
   On 12/25/2025 2:51 AM, Janis Papanagnou wrote:   
   > On 2025-12-25 06:09, BGB wrote:   
   >> On 12/24/2025 5:22 AM, BGB wrote:   
   >>>   
   >>> Some people seem to really like using lookup tables.   
   >   
   > Of course; they can speed up things significantly. And simplify   
   > the operations for contemporary data sizes (bytes, 64 bit words,   
   > etc.).   
   >   
   >>   
   >> I don't really get the point of lookup table driven RNGs.   
   >   
   > In e.g. bit-oriented algorithms (e.g. based on LFSR) you can speed   
   > up processing significantly by processing larger quantities (like   
   > octets/bytes) and processing/accessing values then byte-wise.[*]   
   >   
   > Someone already mentioned that a bit-wise operating PN-generator   
   > for random numbers could make use of such a table driven approach.   
   > (You can extend that principle to larger quantities than bits, e.g.   
   > to gain from larger processor word lengths, especially it you need   
   > those larger entities as result in the first place.)   
   >   
      
      
   I meant, more like this (from Doom):   
   <==   
   unsigned char rndtable[256] = {   
        0,   8, 109, 220, 222, 241, 149, 107,  75, 248, 254, 140,  16,  66 ,   
        74,  21, 211,  47,  80, 242, 154,  27, 205, 128, 161,  89,  77,  36 ,   
        95, 110,  85,  48, 212, 140, 211, 249,  22,  79, 200,  50,  28, 188 ,   
        52, 140, 202, 120,  68, 145,  62,  70, 184, 190,  91, 197, 152, 224 ,   
        149, 104,  25, 178, 252, 182, 202, 182, 141, 197,   4,  81, 181, 242 ,   
        145,  42,  39, 227, 156, 198, 225, 193, 219,  93, 122, 175, 249,   0 ,   
        175, 143,  70, 239,  46, 246, 163,  53, 163, 109, 168, 135,   2, 235 ,   
        25,  92,  20, 145, 138,  77,  69, 166,  78, 176, 173, 212, 166, 113 ,   
        94, 161,  41,  50, 239,  49, 111, 164,  70,  60,   2,  37, 171,  75 ,   
        136, 156,  11,  56,  42, 146, 138, 229,  73, 146,  77,  61,  98, 196 ,   
        135, 106,  63, 197, 195,  86,  96, 203, 113, 101, 170, 247, 181, 113 ,   
        80, 250, 108,   7, 255, 237, 129, 226,  79, 107, 112, 166, 103, 241 ,   
        24, 223, 239, 120, 198,  58,  60,  82, 128,   3, 184,  66, 143, 224 ,   
        145, 224,  81, 206, 163,  45,  63,  90, 168, 114,  59,  33, 159,  95 ,   
        28, 139, 123,  98, 125, 196,  15,  70, 194, 253,  54,  14, 109, 226 ,   
        71,  17, 161,  93, 186,  87, 244, 138,  20,  52, 123, 251,  26,  36 ,   
        17,  46,  52, 231, 232,  76,  31, 221,  84,  37, 216, 165, 212, 106 ,   
        197, 242,  98,  43,  39, 175, 254, 145, 190,  84, 118, 222, 187, 136 ,   
        120, 163, 236, 249   
   };   
      
   int	rndindex = 0;   
   int	prndindex = 0;   
      
   int P_Random (void)   
   {   
        prndindex = (prndindex+1)&0xff;   
        return rndtable[prndindex];   
   }   
      
   int M_Random (void)   
   {   
        rndindex = (rndindex+1)&0xff;   
        return rndtable[rndindex];   
   }   
      
   void M_ClearRandom (void)   
   {   
        rndindex = prndindex = 0;   
   }   
      
   ==>   
      
   Like, why?...   
      
   There are different/better ways of doing RNG.   
      
      
      
   Granted, can't really change this in Doom, because modifying it means   
   that demos will desync (or, at least, more than they desync already).   
   Apparently some source-ports (like ZDoom) put significant effort into   
   immitating the behavior of each version of the Doom engine such that the   
   demos from the corresponding IWADs work (with magic to try to identify   
   the Doom version by pattern-matching the IWAD).   
      
   My port is based on linuxdoom, and doesn't go this far (there was a   
   combination of both algorithmic differences and also Doom to some extent   
   being sensitive to the contents of memory from out-of-bounds memory   
   accesses).   
      
   Had tried copying a few simple tricks from ZDoom, but were not enough to   
   get desync free demo-playback (though, it plays out the same between   
   builds for different targets, ...).   
      
      
      
   Kind of a similar issue with my ROTT port, except that ROTT is more of a   
   mess, and there isn't even consistency between runs, or even necessarily   
   between different runs of the same demo within the demo loop.   
      
   Had sort of got it stabilized, but in the past could seemingly only get   
   consistent desync-free playback when built for 32-bit x86.   
      
      
   But, then again, did at one point investigate why a feature had broken   
   in ROTT, and realized that the code in question was sensitive to (among   
   other things) the specific behavior of a signed-integer overflow when   
   promoting to a larger type (it only worked correctly if it first   
   overflowed at the narrower size and was then promoted; rather than one   
   where it simply did the operation at the wider size with no   
   wrap-on-overflow behavior).   
      
   Well, and also a lot of cases where there was a lot of out-of-bounds   
   accesses, which I then needed to try to hack around to handle in some   
   way "sensible" that was still mostly consistent with the original   
   out-of-bounds access behavior.   
      
   And, some amount of "YOLO" array access, namely accessing one array out   
   of bounds to access stuff in another array mostly depending on their   
   relative locations in memory (this is not a coding style that I   
   particularly consider acceptable, unless maybe the application itself   
   directly controls the memory layout, rather than something that is   
   mostly in the domain of the C compiler or linker).   
      
   Though, there did still end up being a certain amount of "characteristic   
   behavior" changes resulting from fixing up OOB issues.   
      
   Say, for example, if the player manages to get outside the map, rather   
   than the game corrupting memory and crashing; one may find themselves on   
   an infinite plane where the map just wraps around (once every 128 blocks).   
      
   But, despite everything, there is still some sort of lingering   
   non-determinism in the mix here.   
      
   ...   
      
      
   Well, at least my Hexen port seemingly has non-desync'ing demos. And my   
   Heretic port seemingly works correctly with the Shareware WAD I have   
   (but not with a registered WAD; but the registered WAD has a lot more   
   maps vs the Shareware version).   
      
   As with Doom, behavior is mostly consistent across targets. Though, each   
   did require modification to work on ARM, since ARM defaults to unsigned   
   char and the various versions of the Doom engine had contained code that   
   assumed that 'char' was signed (well, along with a lot of obligatory   
   changes in "r_data.c" and similar to deal with 64-bit targets having   
   64-bit pointers and similar, etc).   
      
   ...   
      
      
      
   Some later games (mostly starting with Quake) had instead avoided desync   
   issues by recording game event messages. Rather than trying to record   
   and playback player keyboard inputs and similar.   
      
   Though, in my attempt to port Quake3, I ended up dropping the original   
   QVM as it was designed in a way that wasn't really compatible with   
   64-bit machines (but, the "game" code was also written in C and so could   
   be compiled to native code).   
      
   In my case, one possibility could be (if I want to move away from native   
   code) compiling the "game VM" scripts as RISC-V or similar and then   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)