Update

doom.md

@@ -20,13 +20,14 @@ As stated, the game's backstory was simple and didn't stand in the way of gamepl
 
 *Doom* was followed by *Doom II* in 1995, which "content-wise" was basically just a data disc, the same game with new levels and some minor additions. More Doom games followed, notably *Final Doom* and *Doom 64*, but these are a bit less known now. After the turn of the new millennium *Doom III* came out in 2004, which was a kind of "reboot" rather than a sequel. The game also got an expansion pack. *Doom IV* was in development but got canceled, so the next official game was *Doom 2016* -- another reboot. In 2020 *Doom: Eternal* was released.
 
-Some **[interesting](interesting.md) things** about Doom:
+Some **[interesting](interesting.md) facts** about Doom include:
 
 - 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.
 - In 2024 some researchers made an experimental completely [neural network](neural_net.md) [AI](ai.md) game engine (called GameNGen) and implemented Doom with it -- basically they just made the network play Doom for a long time and so trained it to estimate the next frame from current input and a few previous frames. It can be played at 20+ FPS and looks a lot like Doom but it's also "weird", glitching, and having little persistence (it only remembers a few seconds back). Still pretty impressive.
 - The Crispy Doom engine adds `GOOBERS` cheat code which makes all floors and ceilings the same height, effectively making the game a flat [wolf3d](wolf3d.md)-style game.
 - By simple modification of the engine (making the [pseudorandomness](pseudorandom.md) generator always return the same value, e.g. [zero](zero.md)) it's possible to essentially turn off all randomness and the game then becomes quite weird. For example the "melting" screen effect turn to just a screen swipe, strobe light effects disappear, weapon fire loses any spread and all monsters always make the same death sound.
 - Someone (kgsws) has been [hacking](hacking.md) the ORIGINAL Doom engine in an impressive way WITHOUT modifying the source code or the binary, rather using [arbitrary code execution](arbitrary_code_execution.md) bug; he added very advanced features known from newer source ports, for example an improved 3D rendering algorithms allowing geometry above geometry etc. (see e.g. https://yt.artemislena.eu/watch?v=RdbRPNPUWlU). It's called the Ace engine.
+- A special mod of Doom, called Marine Doom, was at one point used for [military](military.md) training.
 - Doom sprites were made from photos of physical things: weapons are modified photos of toys, enemies were made from clay and then photographed from multiple angles (actually a great alternative to [3D modeling](3d_model.md) that's less dependent on computers and produces more realistic results).
 - The strongest weapon in the game is name BFG9000, which stands for "big fucking gun".
 - There is some kind of "controversial" Doom mod called *Moon Man* where you shoot feminists, jews, niggas and such, apparently it triggers [SJWs](sjw.md) or something.
@@ -44,7 +45,7 @@ The code itself looks alright, files are nicely organized into groups by their p
 
 The game only used [fixed point](fixed_point.md), no [float](float.md)!
 
-The **Doom engine** (also called *id Tech 1*) 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)** (levels were made of convex 2D sectors that were then placed in a BSP tree which helped quickly sort the walls for rendering front-to-back) that was able to render [realtime](realtime.md) 3D views of textured (all walls, floors and ceilings) environments with primitive lighting (per-sector plus diminishing lighting), enemies and items represented by 2D [billboards](billboard.md) ("[sprites](sprite.md)"). 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), and would also later be brought to Doom by newer community made engines, though the original always looks the best). This had its limitations, for example the camera could not look up and down, there could be no tilted walls and the levels could not have rooms above other rooms. The geometry of levels was only static, i.e. it could not change during play (only height of walls could), because rendering was dependent on precomputed BSP trees (which is what made it so fast). For these reasons some call Doom "[pseudo 3D](pseudo3d.md)" or 2.5D rather than "true 3D", some retards took this even as far as calling Doom 2D with its graphics being just an "illusion", as if literally every 3D graphics ever wasn't a mere illusion. 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. Other games later used the Doom engine, such as Heretic, Hexen and Strife. The Doom engine was similar to and competing with [Build](build_engine.md) engine that ran games like [Duke Nukem 3D](duke3d.md), Blood and Shadow Warrior. All of these 90s shooters were amazing in their visuals and looked far better than any [modern](modern.md) shit. Build engine games had similar limitations to those of the Doom engine but would improve on them (e.g. faking looking up and down by camera tilting, which could in theory be done in Doom too, or allowing sloped floor and dynamic level geometry).
+The **Doom engine** (also called *id Tech 1*) 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)** (levels were made of convex 2D sectors that were then placed in a BSP tree which helped quickly sort the walls for rendering front-to-back) that was able to render [realtime](realtime.md) 3D views of textured (all walls, floors and ceilings) environments with primitive lighting (per-sector plus diminishing lighting), enemies and items represented by 2D [billboards](billboard.md) ("[sprites](sprite.md)"). 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), and would also later be brought to Doom by newer community made engines, though the original always looks the best). This had its limitations, for example the camera could not look up and down, there could be no tilted walls and the levels could not have rooms above other rooms. The geometry of levels was only static, i.e. it could not change during play (only height of walls could, which is why walls always opened upwards), because rendering was dependent on precomputed BSP trees (which is what made it so fast). For these reasons some call Doom "[pseudo 3D](pseudo3d.md)" or 2.5D rather than "true 3D", some retards took this even as far as calling Doom 2D with its graphics being just an "illusion", as if literally every 3D graphics ever wasn't a mere illusion. 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. Other games later used the Doom engine, such as Heretic, Hexen and Strife. The Doom engine was similar to and competing with [Build](build_engine.md) engine that ran games like [Duke Nukem 3D](duke3d.md), Blood and Shadow Warrior. All of these 90s shooters were amazing in their visuals and looked far better than any [modern](modern.md) shit. Build engine games had similar limitations to those of the Doom engine but would improve on them (e.g. faking looking up and down by camera tilting, which could in theory be done in Doom too, or allowing sloped floor and dynamic level geometry).
 
 The game data is stored in so called **WAD files** (short for *where's all the data*). While many things are hardcoded in the engine, such as the total number of levels or types of weapons, most other things such as textures, levels, color palettes, weapons and enemy sprites are in the WAD files and so can be replaced without having to mess with the engine itself. There are two types of WAD files (both however still come with the same .wad extension, they are distinguished only by the file magic number): IWAD (internal WAD) and PWAD ([patch](patch.md) WAD). IWAD is the most important one, representing the base game, so for example Doom, Hexen and Freedoom will all have their own specific IWAD. Only one IWAD is loaded at any time. PWAD allows to add or modify things in the IWAD which makes it possible to easily correct bugs in the game data and make mods. Unlike with IWADs, multiple PWADs can be loaded at any time -- when loaded, a resource that's present in the PWAD will override the same resource in the base IWAD. All resources in the WAD files are stored as so called *lumps* which we may simply see as "blobs of data" or "files". A nice [CLI](cli.md) tool for working with WADs is e.g. [deutex](deutex.md).