Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix doom running at 32FPS instead of desired 35 FPS. #6

Merged
merged 1 commit into from Apr 23, 2021
Merged

Commits on Apr 23, 2021

  1. Fix doom running at 32FPS instead of desired 35 FPS.

    A simple typo set the TICRATE to 32 instead of 35.
    The C sources clearly say it should be 35:
    linuxdoom-1.10/doomdef.h:#define TICRATE		35
    
    Wow, I was debugging for so long why I only see 35 FPS in the browser. I was blaming a bad interaction between the 60 FPS the browser renders animations frames vs. the 35 FPS doom likes, which are not a multiple of each other.
    After 12 browser frames and 7 doom frames (at 200ms), both are in sync again.
    
    Here is the python script to simulate how late a doom frame will be:
    
    pdf = 0 # previous doom frame
    for browser_frame in range(12+1):
    	time = browser_frame*1/60*1000 #ms
    	print(f"Broser frame {browser_frame} at {time:.2f} ms")
    	pending_doom_frame = 1/35*1000 * pdf # ms
    	if pending_doom_frame <= time:
    		print(f"  new doom frame for {pending_doom_frame:.2f}; delayed for {time-pending_doom_frame:.2f} ms")
    		pdf += 1
    
    Output:
    Broser frame 0 at 0.00 ms
      new doom frame for 0.00; delayed for 0.00 ms
    Broser frame 1 at 16.67 ms
    Broser frame 2 at 33.33 ms
      new doom frame for 28.57; delayed for 4.76 ms
    Broser frame 3 at 50.00 ms
    Broser frame 4 at 66.67 ms
      new doom frame for 57.14; delayed for 9.52 ms
    Broser frame 5 at 83.33 ms
    Broser frame 6 at 100.00 ms
      new doom frame for 85.71; delayed for 14.29 ms
    Broser frame 7 at 116.67 ms
      new doom frame for 114.29; delayed for 2.38 ms
    Broser frame 8 at 133.33 ms
    Broser frame 9 at 150.00 ms
      new doom frame for 142.86; delayed for 7.14 ms
    Broser frame 10 at 166.67 ms
    Broser frame 11 at 183.33 ms
      new doom frame for 171.43; delayed for 11.90 ms
    Broser frame 12 at 200.00 ms
      new doom frame for 200.00; delayed for 0.00 ms
    
    This means, a doom frame is at most displayed 14.29 ms too late. This seems okayish to me for now.
    
    Simply fixing the typo is good enough for me.
    diekmann committed Apr 23, 2021
    Copy the full SHA
    385e5be View commit details
    Browse the repository at this point in the history