Because the timer latching mechanism used by the vanilla Doom engine on MS-DOS to maintain vertical synchronization was not present in the Linux Doom code base, the game's main loop naturally runs as fast as it can given the amount of time left after game logic processing. This means that, without modification, the released Doom source builds into a program with an essentially uncapped framerate. The game logic is timed to 35 frames per second, but the renderer may be invoked any number of times per tic, effectively rendering the same scene multiple times in a row.
Addition of code to interpolate the positions of actors, sectors, and other game world entities between tics allows a port to take advantage of this and display the game in a way which appears more fluid than the actual simulation will allow without breaking backward compatibility with modifications, DeHackEd patches, or demos. Most use of "uncapped framerate" in the community has come to actually refer to the implementation of this interpolation, and not to the default state of the code base as described above.
Source ports which utilize view interpolation can produce perception of lag in mouse response times. Whether this effect can actually be felt in the controls to the extent of being a nuisance has been disputed, some players claiming they do not notice any difference and others arguing the effect makes the mouse control distinctly worse.
Further criticism includes the feature causing motion sickness and increased eye strain for some users.
For all of these reasons, it is an optional feature in nearly all implementing ports.
Ports with uncapped framerate
- Crispy Doom
- Doom Classic Unity port
- Eternity Engine
- Strife: Veteran Edition
- ZDaemon forums at the