36 ticks per second?

[Nightfall]

From ZDoom Wiki:

Note: Because of a loss of precision with integer division, the duration of a tic is of 28 milliseconds (instead of 28.5714287514...), which means that 35 tics actually make up only 0.98 seconds. There are therefore actually 35.7142857142857... tics in one second.

35.7142857142857 rounds into 36, though 35 seems to be generally used for seconds. What's going on?

[FDARI]

Maybe they rounded down, which is not all that unusual. Somebody may have consciously decided to set the standard at slightly less than a full second rather than slightly more, when the choice needed to be made.

My guess, though, is that somebody decided to have 35 ticks in a second, and found that the integers couldn't perfectly accomodate this. Given a goal of 35 ticks per second, and a reasonably good approximation in the engine, you might present it as 35 ticks per second, make a footnote about the specifics, and assume that nobody will ever have a real need to synchronize Doom with their watches.

[Blzut3]

Code: Select all

// State updates, number of tics / second.
#define TICRATE 		35

The reason for 35 probably stems from Wolfenstein running at 70hz and id deciding in order to accommodate for the increased graphical capabilities they would cut that in half. However, due to how computers work, the engine actually end up using 28ms a tic. This is really not important to the user and the note was merely a technicality previous discussion on the topic. 35 tics is, according to the game simulation, one second.

[Nightfall]

Hmm.. I suppose. Thanks.

[randi]

However, due to how computers work, the engine actually end up using 28ms a tic.

Actually, I doubt this. Doom (probably) used the vblank signal for timing. It ran at a 70 Hz resolution, so it ticked every other screen refresh and got exactly 35 FPS.

[Blzut3]

Actually, I doubt this. Doom (probably) used the vblank signal for timing. It ran at a 70 Hz resolution, so it ticked every other screen refresh and got exactly 35 FPS.

Well outside of the first sentence explaining where 35 comes from, I was mostly speaking in terms of ZDoom. On Windows, the frame rate limiting events are fired every 1000/TICRATE milliseconds (35.714285714...fps). On Linux/Mac OS X the timer is in microseconds so we can fire them every 1000000/TICRATE microseconds (which when you account for the precision loss you get 35.0005250078...fps). This can easily be noticed since in Windows when using cl_capfps you fluctuate between 35 and 36fps where as on Linux you should get a solid 35.