Help porting compat_oldrandom to LZDoom

[drfrag]

I've merged the Zandronum implementation of compat_oldrandom. 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

Quote

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. @Edward850 did you ever try demos or MP? Or someone else? It doesn't seem they worked with your implementation either, i could be wrong obviously. I missed this part but it makes no difference:

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/commit/60cd0fc09d164e09f689dc3a36345f0812a29c24

This was the original ZDoom forum thread:

https://forum.zdoom.org/viewtopic.php?f=4&t=47546

Any help would be appreciated, thanks.

 

[Edward850]

9 hours ago, drfrag said:

@Edward850 did you ever try demos or MP? Or someone else? It doesn't seem they worked with your implementation either, i could be wrong obviously.

It worked in demos and multiplayer because it was a compatflag, of which its status is recorded in demos and ZDoom netgames. However it wasn't about to be able to play vanilla demos or play with Chocolate Doom anytime soon, the compatibility issues with that in ZDoom are far and beyond just that.

[Graf Zahl]

Even if you get all that to work you won't get anything even closely resembling vanilla RNG approximation in many cases because the ZDoom engines has a lot more places that call an RNG, and you have to exclude many of them from being substituted with the classic RNG.

 

The code you added blanketly replaces *ALL* RNG calls which is not what you really want. One RNG you *must* exclude to come even close to vanilla distribution is pr_tracebleed. This gets called frequently in the middle of multi-hitscan attacks and totally screws up your results.

 

You will have to restrict the substitution to those RNG calls that actually exist in Doom originally but not the ones that were added later.

 

 

[LexiMax]

7 hours ago, Graf Zahl said:

The code you added blanketly replaces *ALL* RNG calls which is not what you really want.

 

I agree with Graf here - if you're going to add the old PRNG for weapons, ideally you're going to want two random sources and use the vanilla PRNG in places where it's possible to tell, and the ZDoom's original PRNG everywhere else.  The way Zandronum did it was inelegant and actually caused some problems in places - there was at least one infinite loop caused by the vanilla PRNG due to the fact it wasn't a true PRNG that had to be worked around - some spawning code if I recall.

 

Quote

One RNG you *must* exclude to come even close to vanilla distribution is pr_tracebleed. This gets called frequently in the middle of multi-hitscan attacks and totally screws up your results.

 

That'd actually be an interesting thing to test - it wouldn't change how many 10 and 15 damage pellets are in the random table, but you wouldn't just be getting 256 set patterns anymore.

[drfrag]

Thank you all.

I've managed to compile Edward850's version and demos and MP work. WOW!

There were some errors with VS 2017 and it was broken like all ZDoom versions, i'm not sure if it's another compiler bug (that mscinlines.h misoptimization).

I chose the Zandro version becouse it was simpler and i thought i would need less changes all around the place.

That infinite loop in P_LookForPlayers happened becouse that function was rewritten and there were 64 players there.

I'm trying to port @Edward850's implementation now. My goal is not to play vanilla demos but i think this is important for SP too not only for MP.

@Graf ZahlWhere are the generators defined now? For instance i see pr_troopattack is used in ZScript but i can't find it.

[Graf Zahl]

30 minutes ago, drfrag said:

 

@Graf ZahlWhere are the generators defined now? For instance i see pr_troopattack is used in ZScript but i can't find it.

 

Nowhere, they are being generated from the script source. If the script specifies an RNG that doesn't exist it will allocate a new one with that name implicitly. There's also no guarantee that RNGs won't get merged, they get identified by their name's CRC32, not the name itself.

 

I also thing you are grossly overestimating the importance here. Even Boom in 1998 has replaced the internal RNG with a system similar to ZDoom's and a better distributed generator and that's what gets used most of the time playingor recording in vanilla compatmode. And the lackluster implementation in Skulltag just proves that it's merely a placebo effect taking place, if that was actually accepted by the community. If you do not get the same sequence of RNG calls you won't get the same distributions of numbers and that alone renders the entire thing pointless.

 

[drfrag]

I've noticed they're generated on the fly from ZScript using BuiltinRandom and BuiltinRandom2 so that approach is no longer valid. I could make the checks then in  FRandom::operator()() and FRandom::Random2() again changing the prototypes of NativeRandom and NativeRandom2?

I thought PRBoom still used the old RNG for demos. Then where is that "better distribution"? It would be great to have that instead, but that PRBoom code is a mess.

I don't think i'm overestimating anything, i definitely see the difference now with and without that compat flag in Zandro and it feels like weapons are nerfed in ZDoom specially the regular shotgun. Okay i admit you have to be an absolutely hardcore player to see the difference but i do.

There are some user published stats and that "better distribution" could explain the better output in PRBoom, i actually never play PRBoom but i see the difference with RUDE now.

Quote

if you're actively looking for it the vanilla RNG is weighted high so everything will do slightly more damage.

 

[LexiMax]

1 hour ago, Graf Zahl said:

I also thing you are grossly overestimating the importance here. Even Boom in 1998 has replaced the internal RNG with a system similar to ZDoom's and a better distributed generator and that's what gets used most of the time playingor recording in vanilla compatmode. And the lackluster implementation in Skulltag just proves that it's merely a placebo effect taking place, if that was actually accepted by the community. If you do not get the same sequence of RNG calls you won't get the same distributions of numbers and that alone renders the entire thing pointless.

 

Sorry, Graf, but people who play Deathmatch can 100% tell the difference in the SSG damage.  The numbers in the table just so happen to cause 10 and 15 damage pellets in the SSG than 5 pellets, and when you consider the fact that the SSG fires 20 pellets at a time, even though the exact patterns might not be the same, at the end of the day it's still 20 random numbers from that table, and you're still going to be drawing more 10 and 15 pellets on average.

 

Outside of this narrow case, I actually agree with you.  But in this specific case, players are not imagining things.

[Graf Zahl]

Well, that should make things a lot easier for drfrag: Just make an alternative of A_FireShotgun2 and call it a day. :)

 

[LexiMax]

Yeah, if ZScript can do that, then that's almost certainly the better play, compared to coming up with yet another compatflag.

[drfrag]

It's not that simple unfortunately. I've checked that using the old rng for all the generators in Edward850's version MP and demos still work. So must be something new. Torr said the code would need to be adjusted for ZDoom but in Edward850's version the table is used even in more FRandom functions.

I could try to disable the flag for some new generator added later but i'm lost now. Which new generators are used only in MP or demos? Doesn't look like that's the problem tough, i know that the rngseed is stored in demos and passed in network packets same as before.

pr_tracebleed shouldn't be a problem right the opposite, i don't intend to play demos and the "randomness" comes from the multiple accesses to the table increasing the index. If i used it only for the SSG it would be always the same. But my main concern is the shotgun in SP and then the chaingun.

 

[drfrag]

Disabling the wipe fixes demos and MP games desync later without that code snippet in StaticSumSeeds() posted above.

[Blzut3]

4 hours ago, drfrag said:

If i used it only for the SSG it would be always the same. But my main concern is the shotgun in SP and then the chaingun.

If you really want to be more liberal in the application I'd probably recommend covering all the rngs related to damage dealt.  Leaving all physics/game logic rngs on the mersenne twister.  (I know the spawn spots were also mentioned, but my personal opinion is if the goal was spawn randomly then the MT is definitely a fix.  I know competitive players will have a different opinion, but I've never really agreed with competitive players on these things.  I mean there have even been discussions on Zandronum for completely removing the RNG for competitive play.)

4 hours ago, drfrag said:

games desync later without that code snippet in StaticSumSeeds() posted above.

While including the global old rng index in StaticSumSeeds is probably the right thing to do, I think this is only used to determine if it should print that the games are out of sync.  So not sure why that would fix any sync issue, just let you know sooner if a sync issue occurred.

4 hours ago, drfrag said:

Disabling the wipe fixes demos

So your issue with the Zandronum implementation is probably because some of the FRandom instances are used for visual randomness which isn't synced between clients/demos.  Off hand I don't know if there's any other such rng besides M_Random that needs to be excluded.

5 hours ago, AlexMax said:

Yeah, if ZScript can do that, then that's almost certainly the better play, compared to coming up with yet another compatflag.

Although it would be a much more tedious (20 individual calls to A_FireBullets) it honestly probably could have been done with DECORATE+ACS this whole time.  Don't recall if that was ever attempted for Zandronum but kind of doesn't matter now. :P

[Edward850]

9 minutes ago, Blzut3 said:

(I know the spawn spots were also mentioned, but my personal opinion is if the goal was spawn randomly then the MT is definitely a fix.  I know competitive players will have a different opinion, but I've never really agreed with competitive players on these things.  I mean there have even been discussions on Zandronum for completely removing the RNG for competitive play.)

It isn't so much about the randomness of spawns, but rather the very first spawns while technically random were 100% consistent for that map because of Doom's fixed RNG table. It became part of the metagame.

[drfrag]

Thanks. I've done some debugging of the index and it has to be used for something else before the game starts not just the wipe. In Edward version it gets increased only when doing things ingame like shooting, in GZDoom it's increasing all the time albeit slowly like every second. The less intrusive approach regarding code changes would be to forbid usage of P_Random for those new engine things instead of allowing it per rng. Else i'd need to do a massive amount of changes on the ZScript side.

@Graf ZahlDo you know what those new things could be? Are those new generators defined in C++ or generated from ZScript? Becouse the approach would be different.

[drfrag]

Hey, it's fixed. :D

The UseOldRNG boolean was not initialized in the default constructor, it was the same in the original Edward850's implementation. It wasn't a problem in ZDoom but here it is. Now i could disable the old rng for some generators.

[drfrag]

I've pushed the changes, i've disabled the flag only for a few PRNGs for now.

https://github.com/drfrag666/gzdoom/commit/f920a928bbe082bde9821894ade033ea021de83b

[drfrag]

I've uploaded a couple of devbuilds: https://devbuilds.drdteam.org/lzdoom/

It's in the Doom strict compatibility mode. I've added a new sv_stricterdoommode cvar to override some settings too, works best in software mode.

Now the engine starts in a new half native scale mode, remember that softpoly is the default.