Difference between revisions of "Uncapped framerate"
From DoomWiki.org
| [checked revision] | [checked revision] |
(This article is written in an overtly negative fashion. Remove criticism from the introductory sentence as it is redundant to content in the criticism section. Add technical information.) |
m (→External links: use ZDaemonforums template) |
||
| (11 intermediate revisions by 6 users not shown) | |||
| Line 1: | Line 1: | ||
| − | '''Uncapped framerate''' is a feature implemented by various [[source port]]s that removes [[vanilla Doom]]'s hardcoded framerate cap of 35 frames per second. | + | '''Uncapped framerate''' is a feature implemented by various [[source port]]s that removes the [[vanilla]] [[Doom engine]]'s hardcoded framerate cap of 35 frames per second. |
==Implementation== | ==Implementation== | ||
| − | Because the timer latching mechanism used by the | + | 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 [[actor]]s, [[sector]]s, 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 [[demo]]s. 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. | Addition of code to interpolate the positions of [[actor]]s, [[sector]]s, 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 [[demo]]s. 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. | ||
==Criticism== | ==Criticism== | ||
| − | Source ports which utilize view interpolation can | + | 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. | Further criticism includes the feature causing motion sickness and increased eye strain for some users. | ||
| Line 14: | Line 14: | ||
==Ports with uncapped framerate== | ==Ports with uncapped framerate== | ||
| + | * [[Crispy Doom]] | ||
| + | * [[Doom Classic Unity port]] | ||
* [[Doomsday]] | * [[Doomsday]] | ||
| + | * [[EDGE]] | ||
* [[Eternity Engine]] | * [[Eternity Engine]] | ||
* [[GZDoom]] | * [[GZDoom]] | ||
| Line 20: | Line 23: | ||
* [[PrBoom+]] | * [[PrBoom+]] | ||
* [[Risen3D]] | * [[Risen3D]] | ||
| + | * [[Skulltag]] | ||
| + | * [[Strife: Veteran Edition]] | ||
| + | * [[Woof]] | ||
* [[Zandronum]] | * [[Zandronum]] | ||
| + | * [[ZDaemon]] | ||
* [[ZDoom]] | * [[ZDoom]] | ||
==External links== | ==External links== | ||
| − | * | + | * {{ZDaemonforums|t=11405|Uncapped framerate discussion}} at the [[ZDaemon]] forums |
[[Category:New features]] | [[Category:New features]] | ||
Latest revision as of 09:54, 20 February 2021
Uncapped framerate is a feature implemented by various source ports that removes the vanilla Doom engine's hardcoded framerate cap of 35 frames per second.
Implementation[edit]
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.
Criticism[edit]
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[edit]
- Crispy Doom
- Doom Classic Unity port
- Doomsday
- EDGE
- Eternity Engine
- GZDoom
- Odamex
- PrBoom+
- Risen3D
- Skulltag
- Strife: Veteran Edition
- Woof
- Zandronum
- ZDaemon
- ZDoom
External links[edit]
- Uncapped framerate discussion at the ZDaemon forums
