Old RNG compat test (test branch for testing related tests)

[edward850]

A complaint that crops up from time to time is apparently the SSG's behaviour seems slightly off, which may be attributed to the RNG table differences between regular Doom and ZDoom. This particular function hopefully resolves this issue by providing an "old PRNG" compat flag.
I would appreciate people giving this a quick spin and making sure I haven't accidentally the code. Simply flip on "Use the original Doom's Pseudo RNG" in the compatibility options menu. Doom's original table is used, along with every function that used Doom's PRNG. So new functions will have no effect on the PRNG (and thus also unaffected by its limitations), but all old/original functions will use it as a shared table (as per original behaviour).
I'll go about merging this if no issues arise (and nobody finds any actual reason not to merge this ).

Get it here (ZDoom 2.8pre-1118-gb05af7b [OldRNG].7z, 8.35MB) (Branch here)

[Graf Zahl]

While I appreciate the feature very much, I have some problems with the implementation:

- you somehow managed to mess up AActor::StaticSpawn by getting one random value up front and using it for everything in this function instead of choosing an RNG and get several different values out of it.
- Under no circumstances must this be used when either recording or playing back a demo or when playing a multiplayer game. Not even Boom tried this due to sync problems. That was the main reason the different RNGs were implemented for. And even if you choose to have them enabled, the demos need to be flagged.

[edward850]

- you somehow managed to mess up AActor::StaticSpawn by getting one random value up front and using it for everything in this function instead of choosing an RNG and get several different values out of it.

It made more sense at the time. I was aiming for making the SSG sync reliant with Vanilla, by mapping out the number of RNG calls for each rotation. For whatever reason, Doom maps a "player target number" to absolutely everything that spawns, even things that don't need it (for example, bullet puffs, and hence the change).
Easy enough to keep that and the floatbob RNG separate, however. Edit: Aaaannndd done.

- Under no circumstances must this be used when either recording or playing back a demo or when playing a multiplayer game. Not even Boom tried this due to sync problems. That was the main reason the different RNGs were implemented for. And even if you choose to have them enabled, the demos need to be flagged.

I have no idea why Boom would have so many troubles with it, seeing as Doom goes out of its way to reset the RNG every new game, and it'll be straightforward to flag which PRNG is being used. In ZDoom, Compatflags are synced (one would damn hope so ), and thus the old RNG flag is too. Assuming multiplayer and demos are resetting the RNG tables like they're supposed to, the index will stay in sync as well.

I'll do some thorough tests, but I implemented it the way I did to make sure no such issues would arise. This did also mean skipping old PRNG calls for random sound indexes, simply because I doubt they stay in sync with console specific sounds (although, I would a love an excuse to go in and remove consoleplayer checks from within the playsim code for sanity reasons. ).

Besides, the complaint usually comes up in multiplayer (deathmatch, specifically), so it would be partly missing the point if it didn't work in it.

Edit: While are are on the subject of the SSG, is the P_LineAttack pitch supposed to be multiplied by 332063? Vanilla does <<5, and while 332063>>16 does indeed equal 5, 5<<16 is actually 327680. Is there something about the fixed point difference of 0.0668792724609375 I'm not grasping, here?

[randi]

This seems like a bunch of nitpicky hogwash to me.

[edward850]

I can tell you off the bat that the damage values are vastly different from it. The SSG eats vanillas PRNG pages, and as such the damage values come out a lot more uniform. SFML, while more random, is also exactly that, and frequently will pump out an SSG shot more/less powerful than Doom ever originally could (You can get a shot that's mostly 5's or 15's, while this is impossible with the old PRNG).

I updated the build which shows off said damage values that A_FireShotgun2 produces.

[AlexMax]

This seems like a bunch of nitpicky hogwash to me.

That's what I thought until I ran the numbers a few years ago. Using the old random table increases the likelihood of individual pellets rolling 10 or 15 damage compared to 5, and across 20 pellets this adds up. I have also done blind tests with players using Zandronum's version of the feature, and good players can definitely tell the difference.

IIRC, using the PRNG table also caused players to have the exact same initial deathmatch spawn on a given map.

[randi]

Then what about modifying just the SSG to model the original sequence more closely? I really don't like seeing code changes all over the place just for the sake of one weapon.

[edward850]

It's more about the subtleties, and the SSG is just the more obvious example. Anything that uses a damage-per-trace method will have the same problem, such as the BFG and the shotgun. And as AlexMax also pointed out, deathmatch spawns are affected as well.
Really, this is something that people notice more frequently in deathmatch, and I have no doubt they'll notice it after playing for 20 years. It is a usability edgecase, but no doubt one that particular people notice.

[Enjay]

But, to play devil's avocado, I'd suggest that if you are using ZDoom, then the game has already changed in many subtle ways, especially if you are playing with mouse aiming etc, and the current ZDoom behaviour is now almost as old and established as the original Doom behaviour.

[edward850]

Hence the creation of this thread. People often complain that base ZDoom feels like "change for the sake of change", and I would have liked to gauge if anybody actually liked the old PRNG, or if it was merely a placebo effect or the issue itself was elsewhere.
ZDoom does change the line tracing dramatically (I can't get Vanilla and ZDoom scattered line traces to match even remotely with the same supposed input), and the problem may have been that, but it is a little harder to replicate.

You know, just a little.

[Gez]

For what it's worth, Zandronum already features this option and the original PRNG is also standard in ZDaemon and Odamex.

[Blzut3]

But, to play devil's avocado, I'd suggest that if you are using ZDoom, then the game has already changed in many subtle ways, especially if you are playing with mouse aiming etc, and the current ZDoom behaviour is now almost as old and established as the original Doom behaviour.

There's a segment of the Doom community that has established ZDaemon as a standard for competitive play. (Yes, ZDaemon and not vanilla despite what they will claim.) It would only make sense that edward850 would be asked to implement similar features into ZDoom. These people typically don't play with freelook and jump and only play vanilla compatible maps. Graf's suggestion to not allow it in multiplayer or demos is thus completely defeating the purpose of the flag.

With that said, I do agree with an option to use the old rng table as it can indeed make noticeable differences in cases where it is called many times without entropy. I like edward's implementation over Zandronum's as well. One thing that bothered me about the switch on Zandronum is that it changed all RNGs and people would commonly toggle the switch on under the impression that the old behavior is better. (Or rather they read the flag description as "fix the SSG.") However, this means that everything designed with the new RNG in mind is now using a broken RNG. edward's implementation seems to be opt in per RNG instance which should fix the feel of the SSG and similar weapons without handicapping the rest of the engine.

[drfrag]

I've revisited this and merged the Zandronum implementation of compat_oldrandom, it's simpler and well tested. I've noticed that weapons do less damage in ZDoom than in regular Doom, i play RUDE too you know, specially it's harder to kill an imp with a single shotgun shot. I don't think this is a myth and there are even some stats, to prove it i'd need to do some debugging however.
But not surprisingly it only works in SP, both demos and MP games desync (DM inmediately, coop after doing something). Torr's implementation didn't reset the index, i've added that and the flag to the doom strict compatibility mode. Now i'd like to fix MP and i have no idea how.
https://zandronum.com/tracker/view.php?id=31

Skulltag's implementation needs to be adjusted to be used in ZDoom. Otherwise you most likely would get sync problems in ZDoom's multiplayer and in single player demos.

About the stats there for PRBoom i feel it's the same as ZDoom, i don't know how that user got higher damage values.
I'll ask Torr. Did Edward850 even tried demos or MP? Or someone else? It doesn't seem they worked with his implementation either. I missed this part but it makes no difference:

Code: Select all

diff --git a/src/g_game.cpp b/src/g_game.cpp
index 0d95182aa..75a6b6be9 100644
--- a/src/g_game.cpp
+++ b/src/g_game.cpp
@@ -1074,7 +1074,8 @@ static uint32_t StaticSumSeeds()
 		pr_spawnmobj.Seed() +
 		pr_acs.Seed() +
 		pr_chase.Seed() +
-		pr_damagemobj.Seed();
+		pr_damagemobj.Seed() +
+		prndindex;

https://github.com/drfrag666/gzdoom/com ... 0812a29c24

[drfrag]

It's fixed. The discussion is here: https://www.doomworld.com/forum/topic/1 ... to-lzdoom/
https://github.com/drfrag666/gzdoom/com ... ea021de83b