Difference between revisions of "Talk:Pseudorandom number generator"

From DoomWiki.org

(Re: analyzing RNG with finite statistics)
Line 13: Line 13:
  
 
:: I think that, in some source ports, demos can be viewed from different camera angles.  Assuming different views might have different need for random numbers, the two-function approach ensures the demo play itself will be the same irrespective of the view. [[User:Radius|radius]] 02:39, 8 Nov 2005 (UTC)
 
:: I think that, in some source ports, demos can be viewed from different camera angles.  Assuming different views might have different need for random numbers, the two-function approach ensures the demo play itself will be the same irrespective of the view. [[User:Radius|radius]] 02:39, 8 Nov 2005 (UTC)
 +
 +
''The mean value is 128.852, whereas it would be 127.500 if all values were equally likely.''  It should be pointed out that damage calculations for weapons and monsters use the low bits from the numbers in m_random.c, not the high bits, so this kind of statistic tells at most half the story.    [[User:Ryan W|Ryan W]] 20:38, 17 November 2006 (UTC)

Revision as of 15:38, 17 November 2006

This article is interesting, although the example isn't clear enough for me to understand. Would a pitched sound being played at different frequencies for two different observers desync the game? Why? I don't think the reason for two tables is clear enough. It is mentioned they are identical; are the tables identical too?

If Player1 hears 2 sounds, and Player2 hears 1, then on the next tic, they will have different random indexes, and could, for example, calculate different damage (so an imp could die on one persons computer, but the others) So only game-state stuff is handled in one, and other random stuff is handled in the other.

The first revision mentioned the ClearSomething-or-other function for resetting the index into the table, rationale: demo playback at level start etc. This has been excised and should be worked back in. -- User:JDowland

Your first question: a pitched sound played at different frequencies for two different observers would not descync the game. As the game is implemented, the sounds heard by any player do not affect the state of the simulation in any way.
That said, I don't think two functions are needed for demo synchronization, only multiplayer. (The M_Random function is needed in case a random number is needed on one machine but not necessarily all of them in a multiplayer game.) So I have removed the word "demo" from that part.
Your second question: there is only a single, shared table.
The M_ClearRandom function description was not excised, it is in all versions of the article, just perhaps moved/modified a bit. -- radius 02:09, 8 Nov 2005 (UTC)
I think that, in some source ports, demos can be viewed from different camera angles. Assuming different views might have different need for random numbers, the two-function approach ensures the demo play itself will be the same irrespective of the view. radius 02:39, 8 Nov 2005 (UTC)

The mean value is 128.852, whereas it would be 127.500 if all values were equally likely.  It should be pointed out that damage calculations for weapons and monsters use the low bits from the numbers in m_random.c, not the high bits, so this kind of statistic tells at most half the story.    Ryan W 20:38, 17 November 2006 (UTC)