This commit is contained in:
Miloslav Ciz 2025-04-08 21:14:43 +02:00
parent 362a9efe1f
commit 8ac0ebb55b
10 changed files with 2041 additions and 2014 deletions

View file

@ -14,7 +14,9 @@ The game was met with hilarious [censorship](censorship.md) as there are swastik
## Code/Engine
The game is written in [C89](c.md) (with some bits in [assembly](assembly.md)) and consists of 70 files that count roughly 30000 [lines of code](loc.md) (depending on how we count). Formatting and [comments](comment.md) look like garbage, tabs are mixed with spaces and stuff, a bunch of empty lines suddenly appear for no reasons, also great many ifdefs everywhere etc.
The game is written in [C89](c.md) (with some bits in [assembly](assembly.md)) and consists of 70 files that count roughly 30000 [lines of code](loc.md) (depending on how we count). Formatting and [comments](comment.md) look like garbage, tabs are mixed with spaces and stuff, a bunch of empty lines suddenly appear for no reasons, inconsistencies (sometimes a function is called like `f ()`, sometimes `f()`), also great many ifdefs everywhere etc. Yep, there are [gotos](goto.md) too.
System requirements were 528 KB [RAM](ram.md), 3 MB of disk space and 286 CPU (8 MHz).
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.
@ -28,6 +30,10 @@ A lesser known piece of trivia is that the [SNES](snes.md) port of Wolfenstein a
To quickly scale sprites and wall textures a clever [optimization](optimization.md) was used, called *scalers*. A scaler was essentially compiled code that would take an image and draw its scaled version without any parameters, branching or condition checking; the point is there was a scaler for every possible "stretch", so this is a kind of precomputation sacrificing memory to win speed. Precomputation is after all a theme present in the whole engine, just like in Doom -- there is a precomputed [sine](sin.md) table, table of [pseudorandom](pseudorandomness.md) numbers etc.
[AI](ai.md) is based on [finite state machine](fsm.md). Enemies always occupy a single square -- when changing square the motion is [interpolated](interpolation.md) to create an illusion of smooth motion. Thinking actors are represented by `objtype` struct. There is one remarkably advanced feature to the AI system: sound propagation. Enemies can be awoken when they hear a noise and this takes into account separate rooms and closed/open doors. This was again made possible by a precomputed table that marks parts of the map as "acoustically connected".
**[Interesting](interesting.md) places in code**: `ID_US_A.ASM:19`: pseudorandom number table; `WL_MAIN.C:1586`: the C main function; `WL_GAME.C: 1233`: game loop; `WL_PLAY.C:1368`: play loop (funnily there is a hint of some kind of [virtual reality](vr.md) support? See the variable `virtualreality`); `WL_DRAW.C:1336`: the raycasting function.
## See Also
- [Doom](doom.md)