-timedemo glitch

[myk]

Does anyone know why Doom's -timedemo sometimes produces weird results? For example, this demo I was watching gives an output of "timed 15861 gametics in 43 realtics". Gee, that was fast; my video card kicks ass! But not really. And it's not something that happens too rarely, either.

[Opulent]

Is this the latest prboom versions?
perhaps it skips frames?

[myk]

Opulent said:
Is this the latest prboom versions?

Huh?

perhaps it skips frames?

I think I found something; in those demos I had exited the map, just entered the next, and quit. So apparently the realtics value was the total tics on the new map, while the gametics referred to the whole recording. Maybe the code can explain that.

[RjY]

myk said:

I think I found something; in those demos I had exited the map, just entered the next, and quit. So apparently the realtics value was the total tics on the new map, while the gametics referred to the whole recording. Maybe the code can explain that.

Yes this is pretty much what is happening.

When Doom loads a map it sets a variable called starttime to the current wall clock time (G_DoLoadLevel in linuxdoom-1.10/g_game.c) Then when the demo finishes, it reads the current wallclock time again. The difference between these two is the number of realtics (G_CheckDemoStatus in linuxdoom-1.10/g_game.c)

Also there is a variable called gametics which starts off at zero and is incremented each time the world is updated (D_DoomLoop in linuxdoom-1.10/d_main.c, specifically the if (singletics) clause)

So if your demo starts on one map but goes onto another, then when the second map is loaded starttime is reset, but gametics isn't. So when the demo ends a short time into the subsequent map, you'll get a very small wall clock difference time but a high number of gametics.

If this is happening in demos which exit before the next map is loaded then I don't know what's going on!