[silikone]

Is there any specific frame rate that the game is locked at?
I always assumed it was 70Hz, seeing as this is the update rate of the old VGA mode that the vanilla game defaults at. However, I have seen several references to a rate of 120Hz, and indeed, this number appears to show up in the source code for some timing stuff. When I wanted to confirm this by using the DNRATE cheat, I got a number that could reach four digits, suggesting that there is no limit at all.
So which number should one believe in?

[oasiz]

What you are seeing are internal tickrates that stuff gets interpolated against. These always use Hz to denote "updates per second" vs. frame rate which is the actual drawing.
Some objects do not get interpolated, which results in motion that looks noticeably lower FPS.

[silikone]

Old topic, but I decided to check out the code and compare it against other versions.
The original code curiously defines the game update rate to be 26, even though integer rounding effectively makes it 30. The tickrate is four times this at 120Hz, defining the interpolation granularity. Any frame rate above this appears to render duplicate frames without ever reaching a hard cap.

EDuke and Megaton both appear to update the mouse at the frame rate, resulting in a much better feeling. Curiously, only the latter also updates the player view at more than 30Hz when standing on a rotating platform. I wasn't able to find the relevant mouse code for Eduke, but the fact that there is some disparity between the console variables found on Github and my client suggests that the build isn't based on the code found on Github.

The takeaway is that the ideal frame rate to lock the game at is a multiple of 30 to minimize inconsistent jitter.

[Radar]

silikone, on 07 May 2020 - 05:36 AM, said:

The tickrate is four times this at 120Hz, defining the interpolation granularity. Any frame rate above this appears to render duplicate frames without ever reaching a hard cap.

I am guessing EDuke32 allows for much finer granularity. Do you know where in the code this is defined?

[silikone]

RADAЯ, on 07 May 2020 - 07:44 AM, said:

I am guessing EDuke32 allows for much finer granularity. Do you know where in the code this is defined?

Not sure if there is something else under the hood, but the code still seems to use the same level of granularity. The constant used here is defined as 120/30.

[TerminX]

EDuke32's Git repo is at https://voidpoint.io/terminx/eduke32. The timing code in current versions of EDuke32 is a bit different and can generate interpolations representative of fractional intervals between different values of the totalclock variable; you will not get duplicate frames at any framerate. One other thing worth mentioning is that Megaton and other older Duke ports don't actually poll input in a way that's tied to the frame rate; it's just done on the same 30Hz timer used for the game tics with the view angle interpolated in the same way as everything else. Moving sectors are currently a bit jerky in EDuke32 because we dropped the view angle interpolation entirely in order to reduce input latency to the minimum possible levels. I will probably have to re-introduce some form of it for a few very specific cases in order to smooth things out in situations where it's the game changing the player's view angle and not the player themselves.

[Radar]

Isn't frame interpolation a longstanding feature of EDuke32 though? I thought so because even old builds of JFDuke3D are very smooth. Can anyone point me to where this is defined in the code? The reason why I'm asking is because I'm trying to implement this into XDuke. Until I saw this thread, I thought XDuke was "skipping" frames. Now I understand that it's drawing duplicates. I would like to have this fixed in my own private repository.

[silikone]

RADAЯ, on 15 May 2020 - 03:09 PM, said:

Isn't frame interpolation a longstanding feature of EDuke32 though? I thought so because even old builds of JFDuke3D are very smooth. Can anyone point me to where this is defined in the code? The reason why I'm asking is because I'm trying to implement this into XDuke. Until I saw this thread, I thought XDuke was "skipping" frames. Now I understand that it's drawing duplicates. I would like to have this fixed in my own private repository.

Well, interpolation has always been a thing, but the lack of timing precision in the Build engine reduces its perceived smoothness severely.
Interestingly, the recently released video from Digital Foundry on Ion Fury touches on this issue. Apparently, the timer is not exactly synced with the refresh rate, so it exhibits stuttering at a regular interval.
What EDuke32 appears to do is bypass the interpolation for the player angle and update it for every rendered frame (I found the relevant line in the voidpoint link that wasn't on Github).

[Radar]

I don't know if that answers my question.

Basically, I'm asking, when did EDuke32 become capable of rendering the game world at frame rates above 120 hz? Where is the earliest rendition of this code?

[Mark]

To get you started, the 120hz option showed up in the menu somwhere bwtween 4593 and 6906

[Radar]

You mean the frame rate limiter? That's not what I'm talking about. The classic renderer has been capable of outputting 120+ FPS since the JFDuke3D and xduke days. What I'm asking is, when did EDuke32 begin rendering the game world at frame rates above 120 hz instead of duplicating frames?

[Hendricks266]

RADAЯ, on 18 May 2020 - 02:02 PM, said:

You mean the frame rate limiter? That's not what I'm talking about. The classic renderer has been capable of outputting 120+ FPS since the JFDuke3D and xduke days. What I'm asking is, when did EDuke32 begin rendering the game world at frame rates above 120 hz instead of duplicating frames?

Look for the commit that introduces the ClockTicks class, and potentially followup ones to improve it.

[Radar]

Hendricks266, on 18 May 2020 - 02:04 PM, said:

Look for the commit that introduces the ClockTicks class, and potentially followup ones to improve it.

Thanks! This gave me all the info I need. It seems this feature was implemented very recently. I thought it may have been something from long ago. The issue that I'm trying to fix with xduke goes back much farther, as even 2003 builds of JFDuke3D are much smoother than xduke. Thanks for the help though.