A few questions....

[idbeholdME]

1. Does the number generator behave the same way in vanilla Doom and ZDoom?


I don't remember how it was in vanilla but here's an example of ZDoom behavior. Let's say I have 50 health, save before a heavy weapon dude, go in and he kills me. The damage he does is something like 10,3,15,9,13. Bam I'm dead. Now if I load the game, go in and get myself killed by him again, the damages are exactly the same as in previous try. This is replicable indefinitely. Also, the shots he fires land exactly in the same places / I get hit by the same shots as before. Now if I do some other stuff before going to him, the damage and his accuracy will be different, but not always.

Now I'm aware of the pseudorandom number generator Doom uses and from what I understand, pretty much everything that happens in the game generates next number, which should change weapon damages, accuracy etc. So why when I load a game, the numbers stay the same for a while (I don't know what determines how long it stays the same) no matter what I do even if it's supposed to be different? Isn't the number supposed to change when I fire a weapon before going in? Hell, even Doomguy's face moving should change the numbers. It just seems like a random interval, before the numbers change.

When I think about it logically, after I load the game, there is a number saved. So taking the previous example, the HWD will do 10 damage thanks to the saved number. But why doesn't the next number change from 3 to something else is beyond me....


2.Why the translucency?


Almsot everywhere I see Doom, there is translucency for projectiles. IIRC, the projectiles in the original Doom were not translucent at all. I disabled it using SLADE (looks much better to me), but why is it so common that translucency is on by deafult?

[vadrig4r]

Regards your second question: many source ports default to transparency on. Some players might prefer it, I'd wager many either didn't notice or weren't/aren't aware that's not what the original looks like.

[scifista42]

1. They're indeed different, and I know what you're talking about and see it as ZDoom's problem as well.
2. For better aesthetic?

[Lila Feuer]

Set r_drawtrans to false in the console for ZDoom.

[idbeholdME]

scifista42 said:

1. They're indeed different, and I know what you're talking about and see it as ZDoom's problem as well.

Glad to have a comfirmation. Is this a known issue? Are they working on an option to use the vanilla number generator?

Cyanosis said:

Set r_drawtrans to false in the console for ZDoom.

I went over some ZDoom console commands in the past but not all of them and missed this one. It sounds like it will do exactly what I want. Will test it when I get home to try it. The alternative solution I did in SLADE was clumsy at best.

[Edward850]

idbeholdME said:

Glad to have a comfirmation. Is this a known issue? Are they working on an option to use the vanilla number generator?

No. Further more:

idbeholdME said:

Now I'm aware of the pseudorandom number generator Doom uses and from what I understand, pretty much everything that happens in the game generates next number, which should change weapon damages, accuracy etc. So why when I load a game, the numbers stay the same for a while (I don't know what determines how long it stays the same) no matter what I do even if it's supposed to be different? Isn't the number supposed to change when I fire a weapon before going in? Hell, even Doomguy's face moving should change the numbers. It just seems like a random interval, before the numbers change.

When I think about it logically, after I load the game, there is a number saved. So taking the previous example, the HWD will do 10 damage thanks to the saved number. But why doesn't the next number change from 3 to something else is beyond me....

Your understanding of Doom's PRNG table is skewed. Time is not a factor in the table, so just standing around doesn't actually do anything (not on its own, anyway). Meanwhile, the hud face isn't actually on the same table, even in Vanilla. There's actually two tables, P and M. P is used for everything playsim related (damage, chase directions, shell spreads), and M is used for everything else (sound pitches, the hud face, the screen wipe). This is so that regardless of what state the local session is in on rendering something (for example they may not have the hudface switched on or play a certain sound), it doesn't affect the playsim table at all.

ZDoom cranks this up to 11. It doesn't have just any old table, it uses the Mersenne Twister to allow for vastly more varied results with its larger and more frequent values (Vanilla's table was only designed to handle bytes and much less frequent calls, and is even missing a few possible values). On top of that, it doesn't just have two tables anymore, it has at least 50. Damage, chasedir, spread, ACS, spawn-bobs and even a few Hexen actors call their own defined tables, with each table generated from different seeds (one seed is created and then incremented for each table to use).

You're right about saved games though. Even in vanilla, the table index is stored. ZDoom continues that approach as saved games are by design comparable to complete states of the simulation at that frame.

idbeholdME said:

2.Why the translucency?

Suffice to say, because translucency in ZDoom is probably older than you (it is to some new users for sure). It was added during the time in which Doom source ports started adding transparency to the renderer, and adding options for it was actually complicated (especially because defining an amount of transparency was restricted to 4ish alphas). Removing it now would actually cause more problems than it would solve, and is pretty much expected to be there.
r_drawtrans is not a recommended way of disabling it. It doesn't disable translucency completely, and can actually break some maps visually if you use it. It also isn't an archived cvar (its state will only exist for that session only, as it's actually an old debug function), and only exists because nobody has been bothered to remove it.

[Spectre01]

idbeholdME said:

2.Why the translucency?


Almsot everywhere I see Doom, there is translucency for projectiles. IIRC, the projectiles in the original Doom were not translucent at all. I disabled it using SLADE (looks much better to me), but why is it so common that translucency is on by deafult?

Translucency really helps with visibility during intense fights. Nothing more annoying than not being able to see anything when you're spamming the BFG while being lit up by two Archviles with huge-ass Manc fireballs flying everywhere.

[idbeholdME]

Edward850 said:

No. Further more:
Your understanding of Doom's PRNG table is skewed. Time is not a factor in the table, so just standing around doesn't actually do anything (not on its own, anyway). Meanwhile, the hud face isn't actually on the same table, even in Vanilla. There's actually two tables, P and M. P is used for everything playsim related (damage, chase directions, shell spreads), and M is used for everything else (sound pitches, the hud face, the screen wipe). This is so that regardless of what state the local session is in on rendering something (for example they may not have the hudface switched on or play a certain sound), it doesn't affect the playsim table at all.

ZDoom cranks this up to 11. It doesn't have just any old table, it uses the Mersenne Twister to allow for vastly more varied results with its larger and more frequent values (Vanilla's table was only designed to handle bytes and much less frequent calls, and is even missing a few possible values). On top of that, it doesn't just have two tables anymore, it has at least 50. Damage, chasedir, spread, ACS, spawn-bobs and even a few Hexen actors call their own defined tables, with each table generated from different seeds (one seed is created and then incremented for each table to use).

You're right about saved games though. Even in vanilla, the table index is stored. ZDoom continues that approach as saved games are by design comparable to complete states of the simulation at that frame.

Thanks for the explanation/correction. So if I understand correctly, pretty much everything in ZDoom has a seperate table and that's why me shooting doesn't change the monster damage?
That brings up a question, why do the numbers change at all then and are not the same from loading a save point at the start of a level to the end of it, if one doesn't affect the other.
I wrote that it just seems/feels like a random interval, but there obviously is something that changes the numbers.

Edward850 said:

Suffice to say, because translucency in ZDoom is probably older than you (it is to some new users for sure). It was added during the time in which Doom source ports started adding transparency to the renderer, and adding options for it was actually complicated (especially because defining an amount of transparency was restricted to 4ish alphas). Removing it now would actually cause more problems than it would solve, and is pretty much expected to be there.
r_drawtrans is not a recommended way of disabling it. It doesn't disable translucency completely, and can actually break some maps visually if you use it. It also isn't an archived cvar (its state will only exist for that session only, as it's actually an old debug function), and only exists because nobody has been bothered to remove it.

I assure you, I played vanilla Doom when I was a kid (my cousin still has his original CD). Registration date doesn't mean much, besides telling you when I found this site, not mentioning I was a regular lurker before. That's why I was bothered by it. If I played only ZDoom, transparency would seem normal to me.

Any other solution then? I just want the transparency on projectiles/effects (explosions and such) gone, not to destroy levels. As I said, I did it using SLADE, manually removing it from every projectile (forgot or missed arachnotrons plasma though). What made me look into how to turn it off was the absolutely disgusting rocket explosion when it was on.

[scifista42]

idbeholdME said:

That brings up a question, why do the numbers change at all then and are not the same from loading a save point at the start of a level to the end of it, if one doesn't affect the other.
I wrote that it just seems/feels like a random interval, but there obviously is something that changes the numbers.

The answer lies in the function for getting a random number. The engine calls it whenever it needs a random number. The function has its own counter that increments whenever the function is called, and the value of the counter along with the RNG table determines the random number that gets returned. In other words, the act of reading a random value is what changes the next random value. Time doesn't matter. The number of times the function was already called is what matters.

[idbeholdME]

scifista42 said:

The answer lies in the function for getting a random number. The engine calls it whenever it needs a random number. The function has its own counter that increments whenever the function is called, and the value of the counter along with the RNG table determines the random number that gets returned. In other words, the act of reading a random value is what changes the next random value. Time doesn't matter. The number of times the function was already called is what matters.

I know how the generator gets to the next number i.e. the basic principle of it.
I'm not asking the correct questions, so bear with me.

It's the multiple tables as opposed to vanilla that confused me (not being able to change the numbers by ME shooting for example). That's clear now.

Now, I leave the first HWD, go to a different one and let him shoot x times. The next damage value will change x times too.
Will the first five damages once again be 10,3,15,9,13 even though it's a different enemy? Or does every seperate monster get assigned different numbers and a different HWD will have different damages? I didn't test this deep before I started this thread.

Or is it bound to the type of the monster that hits? Do different monsters have different tables or use the same one for damage? If I get hit by a zombieman 5 times, will he do 10,3,15,9,13 again or will he have different numbers/accuracy as opposed to the HWD? Can I change the 10 by getting hit by a hell knight before going to the HWD?

If someone answers these question, I think it will be clear to me. I feel like I'm on the cusp of a great revelation so please, have patience with me :)

[scifista42]

As Edward850 said, ZDoom has tens of RNG tables (each one with its own counter) and hundreds of RNG calls happen for different purposes at places all around ZDoom's source code. I don't think there's any comprehensive list of them all - if that's what you were looking for, you'd have to search through ZDoom's source code yourself. I'll just give you a couple examples: When any projectile impacts onto a damagable thing, a specific game logic function is called to deal damage, where the projectile's base damage is to be multiplied by a random value between 1 and 8 (by default, unless it's prevented to do so via DECORATE), and this random value is obtained through a specific table - for all projectiles that ever impact (possibly except those which are hardcoded to be handled differently, by a different function or a different part of the function's code etc.). Or, when an enemy's hitscan attack impacts, another game logic function handles this situation, where the hitscans's base damage is to be multiplied by a random value between 1 and 3 (again, by default, unless it's prevented to do so via DECORATE), and this random value is obtained through another specific table - for all hitscans that ever impact. Generally said, the RNGs are not explicitly bound to a specific monster or type of monster, but to specific functions of the game logic that the monsters (or their projectiles, or the engine itself, etc) are calling.

[Edward850]

scifista42 said:

I don't think there's any comprehensive list of them all - if that's what you were looking for, you'd have to search through ZDoom's source code yourself.

Not a proper one, but debug builds allow you to print a list of all RNG states (and names where applicable).

[Maes]

Edward850 said:

Time is not a factor in the table, so just standing around doesn't actually do anything (not on its own, anyway).

There are some events which do advance the P index, even without player input, and even without awakened monsters: certain random light flickering effects actually use the P table, so simply having such sectors in a map will actually "consume" the table, so time does become a factor. I'm not sure if sound pitch variations also use the P index.

//
// T_FireFlicker
//
void T_FireFlicker (fireflicker_t* flick)
{
    int	amount;
	
    if (--flick->count)
	return;
	
    amount = (P_Random()&3)*16;
    
    if (flick->sector->lightlevel - amount < flick->minlight)
	flick->sector->lightlevel = flick->minlight;
    else
	flick->sector->lightlevel = flick->maxlight - amount;

    flick->count = 4;
}

Now, don't ask me why anybody would consider a light flickering effect to be critical with respect to demo and gameplay repeatability...

[kb1]

The multiple random number slot thing actually came from Boom - it was Lee Killough's wacky idea that giving each random action its own slot would somehow make demo playback have a smaller chance to desync. My answer to that would be: Yeah, maybe for a few seconds/actions, in a few isolated cases, but not really - not for long. If any one of them gets out of sync, it will eventually cause desyncs anyway. And, as shown in this thrad, it makes each of those actions appear a bit less random, as each action now gets it's own repeatable sequence.