This commit is contained in:
Miloslav Ciz 2025-04-14 21:57:02 +02:00
parent 5604db85d2
commit d8f1711fa8
33 changed files with 2096 additions and 2036 deletions

View file

@ -20,7 +20,7 @@ System requirements were 528 KB [RAM](ram.md), 3 MB of disk space and 286 CPU (8
Compared with Doom, Wolfenstein's code shows considerable [shittiness](shitty.md), for example in that the engine **isn't [deterministic](determinism.md)** and literally **uses [floating point](float.md)** (although it looks like float is only used to precompute tables and that actual real time logic then uses [fixed point](fixed_point.md) arithmetic, but still the [dependency](dependency.md) is there). Apparently there are slips and fails such as the pseudorandom number table not containing certain values, item pickups being part of rendering code (so items can't be picked up moving backwards), or a hardcoded FPS for demos due to the fact that with variable FPS the game isn't deterministic.
Wolfenstein's **rendering** is arguably the most commonly examined part of the engine. It uses 1 dimensional [raycasting](raycasting.md) (see also [raycastlib](raycastlib.md)). Textured walls, sliding door and movable walls were implemented; floors and ceilings were not textured. It goes without saying everything was rendered [purely in software](sw_rendering.md), [GPUs](gpu.md) as known today didn't exist yet. The levels were represented as a 2 dimensional [array](array.md) of cells against which rays were cast from the player's position -- every screen column would have one ray cast per rendered frame. The ray was then traced with the [DDA](dda.md) line drawing [algorithm](algorithm.md) to find intersection with the closest wall. The intersection then determined how tall the wall would appear in the corresponding screen column (based on the [distance](distance.md) and perspective), as well as which part of the texture should be used for the column etc. Each wall texture had two versions: lighter and darker, each of which was used for different wall angles to create a primitive but [effective](good_enough.md) illusion of lighting. Level geometry was naturally limited by the square grid: only 90 degree walls could be placed, there weren't any stairs, walls of different heights etc.
Wolfenstein's **rendering** is arguably the most commonly discussed part of the engine, and possibly the most substantial one. It uses 1 dimensional [raycasting](raycasting.md) (see also [raycastlib](raycastlib.md)). Textured walls, sliding door and movable walls were implemented; floors and ceilings were not textured. It goes without saying everything was rendered [purely in software](sw_rendering.md), [GPUs](gpu.md) as known today didn't exist yet. The levels were represented as a 2 dimensional [array](array.md) of cells against which rays were cast from the player's position -- every screen column would have one ray cast per rendered frame. The ray was then traced with the [DDA](dda.md) line drawing [algorithm](algorithm.md) to find intersection with the closest wall. The intersection then determined how tall the wall would appear in the corresponding screen column (based on the [distance](distance.md) and perspective), as well as which part of the texture should be used for the column etc. Each wall texture had two versions: lighter and darker, each of which was used for different wall angles to create a primitive but [effective](good_enough.md) illusion of lighting. Level geometry was naturally limited by the square grid: only 90 degree walls could be placed, there weren't any stairs, walls of different heights etc.
The game used a [256](256.md) [color](color.md) [palette](palette.md). This allowed quick fades of the screen by simply modifying the palette.