The tutorials are great! Thank you for putting this together.

I would like to build on the doom example for my own, "But can it run DOOM" project. Does this project have a LICENSE?

@diekmann

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_frame1/601000 #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.