This commit is contained in:
Miloslav Ciz 2025-04-17 19:16:48 +02:00
parent d624e17688
commit c0fb21debe
21 changed files with 2001 additions and 1985 deletions

View file

@ -24,7 +24,7 @@ Sadly the game also uses [float](float.md), another thumbs down.
The engine is also **fucking [nondeterministic](determinism.md)**, mainly because its physics is FPS dependent (huge brain fart), but even if that was fixed it might not suffice e.g. because of the use of floating point (as C specification leaves room for floating point nondeterminism).
And as if that wasn't enough, the [demo](demo.md) format sucks ass too. While demos in Doom only recorded the player's inputs -- the way it should always be done -- Quake demos literally store the player states such as their positions etc. It's basically a recording of packets coming from the [server](server.md) to the client. This means the demos are bigger, information about input is lost (causing trouble in verifying speedruns for example) and the demo is only playable from point of view it was recorded from. This desperate and disastrous design choice had to be made because the engine is nondeterministic. Here we can see how a bad programming choice quickly snowballs into a gigantic pile of shit.
And as if that wasn't enough, the [demo](demo.md) format sucks ass too. Whereas demos in Doom only recorded the player's inputs -- the way it should always be done -- Quake demos literally store the player states such as his positions etc. It's practically a recording of packets sent from the [server](server.md) to the client. This means the demos are larger, [information](information.md) about input is lost (causing trouble in verifying speedruns for example) and the demo is only playable from point of view it was recorded from. This desperate and disastrous design choice had to be made because the engine is nondeterministic. Here we can see how a bad programming choice quickly snowballs into a gigantic pile of shit.
As for the **3D rendering**: this is probably the nicest part. The engine features a beautifully looking [software renderer](sw_rendering.md) that was very fast ([optimized](optimization.md) in [assembly](assembly.md)). It supported [256](256.md) [colors](color.md) and by default ran in 320x200 resolution that computers back then could handle at 30 FPS. Shortly after the game's release new versions added a support for [GPU](gpu.md) acceleration with [OpenGL](opengl.md), which was of course faster, additionally supported 16 and 32 bit color, higher resolution and pimped up look (transparent water, [bilinear](bilinear.md) texture filtering that actually looks inferior and soulless, ...). We'll be however focusing on the software renderer. It used [Gouraud](gouraud.md) [shading](shading.md) for moving objects (enemies, doors, ...) and precomputed [lightmaps](lightmap.md) for static environment. Just like Doom, [BSP](bsp.md) trees were still used to represent levels, however in Quake they were 3D (while in Doom only 2D). The renderer worked as follows. First [frustum culling](frustum_culling.md) was performed on the BSP tree, removing anything not in the direction of the camera. Secondly there were precalculated potentially visible sets ([PVS](pvs.md)) -- a [data structure](data_structure.md) storing information about which BSP leaves are visible from other leaves, allowing for saving time by disregarding most parts of the level that can't be seen -- this was applied after frustum culling. Backface culling followed and then rasterization itself in front-to-back order. Rasterization was made so as to eliminate overdraw, it was quite complex, based on scanlines formed by projected geometry edges. As another improvements against the Doom engine there were simple [particle systems](particle_system.md) (well, literally just tiny squares), real-time lighting, warping screen effects and fully 3D animated enemy models. Animated models used a MDL format which stored simple vertex animation (no skeletal bullshit) -- the frames were just played one after another without [interpolation](interpolation.md), resulting in a "jerky" animation. Needless to say the models were quite [low poly](low_poly.md) (monsters usually around 300 [triangles](triangle.md)) and had quite low-res textures (around 300x200 pixels).