This commit is contained in:
Miloslav Ciz 2023-07-30 15:00:49 +02:00
parent 486c142b76
commit 9f32c8079a
12 changed files with 38 additions and 10 deletions

View file

@ -8,12 +8,12 @@ Partially thanks to the free release of the engine and its relatively [suckless]
The Doom engine was revolutionary and advanced (not only but especially) video game graphics by a great leap, considering its predecessor [Wolf3D](wolf3D.md) was really primitive in comparison (Doom basically set the direction for future trends in games such as driving the development of more and more powerful [GPUs](gpu.md) in a race for more and more impressive visuals). Doom used a technique called **[BSP rendering](bsp.md)** that was able to render [realtime](realtime.md) 3D views of textured environments with distance fog and enemies and items represented by 2D [billboards](billboard.md) ("sprites"). No [GPU](gpu.md) acceleration was used, graphics was rendered purely with [CPU](cpu.md) (so called [software rendering](sw_rendering.md), GPU rendering would come with Doom's successor [Quake](quake.md)). This had its limitations, for example the camera could not tilt up and down and the levels could not have rooms above other rooms. For this reason some call Doom "[pseudo 3D](pseudo3d.md)" or 2.5D rather than "true 3D". Nevertheless, though with limitations, Doom did present 3D views and internally it did work with 3D coordinates (for example the player or projectiles have 2D position plus height coordinate), despite some dumb YouTube videos saying otherwise. For this reason we prefer to call Doom a **primitive 3D** engine, but 3D nonetheless. However Doom was not just a game with good graphics, it had extremely good gameplay, legendary music and art style and introduced the revolutionary [deathmatch](deathmatch.md) multiplayer, as well as a HUGE modding and mapping community. It was a success in every way -- arguably no other game has since achieved a greater revolution than Doom.
However Doom's success wasn't just due to its graphics, it excelled overall in all areas -- it had brilliant fast and gory gameplay, amazing level design (by John Romero), excellent soundtrack and even a revolutionary [multiplayer](multiplayer.md). The game's backstory was simple and didn't stand in the way of gameplay, it's basically about a tough marine (so called *Doomguy*) on a Mars military base slaying hordes of demos from hell, all in a rock/metal style with a lot of gore and over-the-top violence (chain saws n stuff).
However Doom's success wasn't just due to its graphics, it excelled overall in all areas -- it had brilliant fast and gory gameplay, amazing level design (by John Romero), excellent soundtrack and even a revolutionary [multiplayer](multiplayer.md). The game's backstory was simple and didn't stand in the way of gameplay, it's basically about a tough marine (so called *Doomguy*) on a Mars military base slaying hordes of demons from hell, all in a rock/metal style with a lot of gore and over-the-top violence (chain saws n stuff).
Doom source code is written in [C89](c.md) and is about 36000 [lines of code](loc.md) long. The original system requirements needed roughly a 30 MHz [CPU](cpu.md) and 4 MB [RAM](ram.md) as a minimum. It had 27 levels (9 of which were shareware), 8 weapons and 10 enemy types.
The game only used [fixed point](fixed_point.md), no [float](float.md)!
Doom also has a [deterministic](determinism.md) [FPS](fps.md)-independent physics which allows for efficient recording of demos of its gameplay and creating [tool assisted speedruns](tas.md), i.e. the time step of game simulation is fixed (35 tics per second). Such demos can be played back in high quality while being minuscule in size and help us in many other ways, for example for verifying validity of [speedruns](speedrun.md). This is very nice and serves as an example of a well written engine (unlike later engines from the same creators, e.g. those of [Quake](quake.md) games which lacked this feature).
Doom also has a [deterministic](determinism.md) [FPS](fps.md)-independent physics which allows for efficient recording of [demos](demo.md) of its gameplay and creating [tool assisted speedruns](tas.md), i.e. the time step of game simulation is fixed (35 tics per second). Such demos can be played back in high quality while being minuscule in size and help us in many other ways, for example for verifying validity of [speedruns](speedrun.md). This is very nice and serves as an example of a well written engine (unlike later engines from the same creators, e.g. those of [Quake](quake.md) games which lacked this feature).
LOL someone created a Doom system monitor for [Unix](unix.md) systems called [psDooM](psdoom.md) where the monsters in game are the operating system [processes](process.md) and killing the monsters kills the processes.