If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/id-Software/DOOM shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Stale — last commit 2y ago

• 2 active contributors
• GPL-2.0 licensed
• ⚠ Stale — last commit 2y ago
• ⚠ Small team — 2 contributors active in recent commits
• ⚠ Concentrated ownership — top contributor handles 75% of recent commits
• ⚠ GPL-2.0 is copyleft — check downstream compatibility
• ⚠ No CI workflows detected
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live id-Software/DOOM repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/id-Software/DOOM.

What it runs against: a local clone of id-Software/DOOM — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in id-Software/DOOM | Confirms the artifact applies here, not a fork | | 2 | License is still GPL-2.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 745 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of id-Software/DOOM. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/id-Software/DOOM.git
#   cd DOOM
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of id-Software/DOOM and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "id-Software/DOOM(\\.git)?\\b" \\
  && ok "origin remote is id-Software/DOOM" \\
  || miss "origin remote is not id-Software/DOOM (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(GPL-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"GPL-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is GPL-2.0" \\
  || miss "license drift — was GPL-2.0 at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "linuxdoom-1.10/d_main.c" \\
  && ok "linuxdoom-1.10/d_main.c" \\
  || miss "missing critical file: linuxdoom-1.10/d_main.c"
test -f "linuxdoom-1.10/g_game.c" \\
  && ok "linuxdoom-1.10/g_game.c" \\
  || miss "missing critical file: linuxdoom-1.10/g_game.c"
test -f "linuxdoom-1.10/r_main.c" \\
  && ok "linuxdoom-1.10/r_main.c" \\
  || miss "missing critical file: linuxdoom-1.10/r_main.c"
test -f "linuxdoom-1.10/p_mobj.c" \\
  && ok "linuxdoom-1.10/p_mobj.c" \\
  || miss "missing critical file: linuxdoom-1.10/p_mobj.c"
test -f "linuxdoom-1.10/p_map.c" \\
  && ok "linuxdoom-1.10/p_map.c" \\
  || miss "missing critical file: linuxdoom-1.10/p_map.c"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 745 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~715d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/id-Software/DOOM"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

This is the original 1995 DOOM source code release (v1.10) for Linux, a seminal real-time 3D first-person shooter engine that renders environments using BSP tree spatial partitioning and horizontal/vertical scanline rasterization. It solves the problem of fast software-rendered 3D graphics on 1990s hardware by using a clever combination of BSP preprocessing, column-based rendering, and span drawing to achieve 35 Hz gameplay without hardware acceleration. Monolithic C/C++ codebase split into two main targets: ipx/ contains legacy IPX network abstraction (DOOMNET.C, IPXNET.C) for multiplayer, and linuxdoom-1.10/ contains the core engine with clear module organization (am_map.c for automap, g_game.c for game state, d_main.c for entry point, rendering spread across unnamed files, hu_stuff.c for HUD). Global state lives in doomstat.c; asset definitions in doomdef.h; network protocol in d_net.c.

Game engine researchers, vintage game porters, and systems programmers who want to understand how real-time 3D rendering worked before GPU acceleration, or who are porting DOOM to new platforms (the README explicitly invites ports to favorite operating systems and mentions the codebase is 'quite portable').

This is a stable, complete historical release from 1995 with no active development—it is a code snapshot, not an ongoing project. The README acknowledges the code is 'a long, long time ago' and identifies multiple algorithmic improvements that could be made (BSP for collision detection, better sprite clipping). It represents production-quality software for its era but is best approached as archived source material rather than a living codebase.

High platform fragmentation risk: the README explicitly states 'this code only compiles and runs on linux' and DOS code was withheld due to copyrighted sound libraries, meaning ports to modern systems (Windows, macOS, mobile) require significant adaptation. No test suite, CI/CD, or dependency management present; all build coordination happens via raw Makefiles. The IPX networking code (ipx/ directory) is tied to legacy protocols obsolete for modern internet play.

Nothing—this is a static historical release. No active branches, PRs, or development indicated. The repository serves as documentation of DOOM's original architecture and a base for community ports/modifications (as hinted in the README's 'project ideas' section).

Clone the repository, then build the Linux target: cd linuxdoom-1.10 && make. You will need the original DOOM data files (WAD files) as noted in the README: 'You still need real DOOM data to work with this code.' The Makefile will produce an executable linked against Linux system libraries.

Daily commands: cd linuxdoom-1.10 && make to build; ./doom -iwad doom.wad to launch with a WAD file (requires original DOOM game data). Command-line options in d_main.c control demo playback, skill level, and network mode.

• linuxdoom-1.10/d_main.c — Main entry point and game loop initialization; all contributors must understand how the engine bootstraps and manages the game state.
• linuxdoom-1.10/g_game.c — Core game logic and tick system; handles input, world updates, and game state progression—the central orchestrator of gameplay.
• linuxdoom-1.10/r_main.c — Primary rendering pipeline entry point; critical for understanding how visuals are drawn each frame using the engine's column-based software rasterizer.
• linuxdoom-1.10/p_mobj.c — Mobile object (actor) system: defines all entities in the world and their lifecycle; essential for gameplay mechanics, AI, and physics.
• linuxdoom-1.10/p_map.c — Collision detection and spatial queries; handles line-of-sight, wall interactions, and entity movement—underpins all physical interactions.
• linuxdoom-1.10/doomdef.h — Global type definitions and constants; establishes the vocabulary and limits of the entire codebase.
• linuxdoom-1.10/d_net.c — Network synchronization and multiplayer tick handling; critical for understanding how distributed game state is maintained.

Add a New Monster Type

1. Define the new actor type constant in the mobjtype_t enum and add spawn info to spritedef_t (linuxdoom-1.10/info.h)
2. Populate state table entries in info.c (idle, attack, pain, death frames and transitions) (linuxdoom-1.10/info.c)
3. Add attack and behavior logic in p_enemy.c (check function selection and action code) (linuxdoom-1.10/p_enemy.c)
4. Register spawn callback and add to P_SpawnMapThing in p_mobj.c if map-placeable (linuxdoom-1.10/p_mobj.c)
5. Add item drop logic in p_inter.c if the monster drops items on death (linuxdoom-1.10/p_inter.c)

Add a New Special Sector Effect

1. Define the sector special type constant in doomdef.h (linuxdoom-1.10/doomdef.h)
2. Add sector special handling in P_SpawnSpecials to initialize the effect state (linuxdoom-1.10/p_spec.c)
3. Implement the effect logic in the appropriate p_*.c file (e.g., p_lights.c for lighting, p_plats.c for movement) (linuxdoom-1.10/p_lights.c)
4. Add state transition logic in the effect's T_* function to handle frame-to-frame behavior (linuxdoom-1.10/p_spec.c)
5. Register save/load serialization in p_saveg.c if the effect must persist across save games (linuxdoom-1.10/p_saveg.c)

Add a New Weapon

1. Add weapon type constant to weapontype_t enum in d_player.h and sprite in spritedef_t (linuxdoom-1.10/d_player.h)
2. Define weapon state sequences in info.c (idle, fire, reload, lower, raise) (linuxdoom-1.10/info.c)
3. Implement weapon fire logic and projectile spawning in p_pspr.c (A_Fire* functions) (linuxdoom-1.10/p_pspr.c)
4. Add weapon selection and ammo cost logic in p_user.c and g_game.c (linuxdoom-1.10/p_user.c)
5. Define projectile actor type with collision behavior in p_mobj.c and p_map.c (linuxdoom-1.10/p_mobj.c)

Add a New HUD Element

1. Define layout coordinates and styling constants in hu_stuff.h (linuxdoom-1.10/hu_stuff.h)
2. Implement draw function in hu_stuff.c that reads player state and renders to screen buffer (linuxdoom-1.10/hu_stuff.c)
3. Call your draw function from HU_Drawer in hu_stuff.c after other HUD elements (linuxdoom-1.10/hu_stuff.c)
4. Add any text/graphic resources (sprites, fonts) via WAD lump loading in r_data.c (linuxdoom-1.10/r_data.c)

The code assumes a 320×200 VGA linear framebuffer (common in DOS/Linux 1995 but obsolete now)—porting to modern displays requires framebuffer scaling. Global state is scattered across doomstat.c and doomdef.c with minimal encapsulation; no thread safety. The 35 Hz tick rate is hardcoded throughout; changing it breaks network sync. IPX networking requires a 1990s-style LAN or compatibility layer (no TCP/IP). The rendering pipeline is tightly coupled: BSP tree generation happens at level load, and sprite clipping assumes specific subsector fragment assumptions (README hints these could be redesigned).

• Binary Space Partition (BSP) tree — DOOM's rendering engine uses BSP preprocessing to partition level geometry and enable fast front-to-back rendering without sorting; understanding BSP is essential to decoding the render pipeline referenced in README.
• Scanline rendering / column-based drawing — DOOM renders vertical strips (columns) of the screen in sequence rather than pixels, exploiting cache locality and enabling efficient span clipping—core to why it ran fast on 1995 CPUs.
• Fixed-point arithmetic — The engine avoids floating-point for speed; all coordinates use fixed-point (integer + fractional bits); visible throughout d_main.c and rendering code.
• Sprite billboarding — Enemies and items are drawn as 2D billboards (always facing camera); the README explicitly mentions sprite clipping complexity, making this a key DOOM innovation.
• Ticking game loop / deterministic lockstep multiplayer — DOOM uses a fixed 35 Hz tick rate and d_ticcmd.h to synchronize multiplayer; all players execute the same ticcmds in order, enabling bit-perfect replay and LAN sync without physics simulation.
• IPX protocol (Internetwork Packet Exchange) — The ipx/ modules implement Novell IPX/SPX for LAN multiplayer—a critical 1990s networking stack now obsolete, illustrating why platform-specific code rots.
• Polar-coordinate clipping (mentioned in README) — The README identifies this as a regrettable design choice in collision detection; understanding why polar coordinates are inferior to BSP clipping teaches valuable 3D geometry lessons.

• id-Software/Quake — Successor engine (1996) that addresses several DOOM limitations mentioned in the README (BSP for collision, edge bevels for polyhedra).
• id-Software/Quake-2 — Further refinement of Quake's architecture; implements the client/server model hinted at in DOOM's project ideas.
• chocolate-doom/chocolate-doom — Modern, actively maintained port of DOOM that preserves original behavior while adding cross-platform support (Windows, macOS, Linux).
• fabriceci/DOOM-3-BFG — Companion codebase: DOOM 3's redesign of the engine using modern graphics (OpenGL/GPU) while maintaining gameplay compatibility.
• DavidBetz/esp32-doom — Example community port demonstrating how to adapt DOOM's rendering to constrained embedded hardware (ESP32), validating the README's portability claim.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Extract and modernize IPX networking layer into platform-agnostic abstraction

The ipx/ directory contains DOS-era IPX protocol implementations (IPXNET.C, DOOMNET.C) tightly coupled to legacy networking. Modern ports (Windows, macOS, BSD) need network abstraction. Create a new i_net_ipx.c wrapper that abstracts IPX behind a clean interface, allowing platform-specific implementations without duplicating protocol logic. This directly enables the cross-platform ports mentioned in README as 'straightforward to bring up.'

• [ ] Create linuxdoom-1.10/i_net_ipx.c as a thin wrapper around ipx/DOOMNET.C
• [ ] Define platform-independent network packet structures in a new i_net_common.h
• [ ] Update i_net.c (the platform layer) to conditionally call i_net_ipx.c, preparing for platform-specific overrides
• [ ] Add build flags to Makefile for enabling/disabling IPX support per platform

Document platform-specific implementation requirements in README.porting

README.TXT mentions 'quite portable' and 'straightforward to bring up on just about any platform,' but there is no porting guide. The i_*.c files (i_video.c, i_sound.c, i_net.c, i_system.c, i_main.c) are the platform abstraction layer. Contributors attempting ports to Windows/macOS need explicit docs on which functions to override.

• [ ] Create linuxdoom-1.10/README.porting documenting the i_*.c interface contract
• [ ] List required functions from i_video.h, i_sound.h, i_net.h, i_system.h with signatures
• [ ] Add a section explaining the relationship between platform-independent code (d_.c, g_.c) and platform layer (i_*.c)
• [ ] Reference existing Linux implementations in i_video.c and i_sound.c as examples

Add input validation and bounds-checking refactor for m_fixed.c and m_bbox.c

The math utility modules (m_fixed.c for fixed-point arithmetic, m_bbox.c for bounding boxes) handle low-level geometry operations used throughout the engine. These are candidates for integer overflow/underflow bugs common in 1990s code. Adding defensive checks and unit test scaffolding improves stability and prevents crashes in custom mods or ports.

• [ ] Review m_fixed.c for fixed-point multiplication overflow (fixed_t mul likely lacks overflow detection)
• [ ] Review m_bbox.c for bbox intersection edge cases and add bounds assertions
• [ ] Create linuxdoom-1.10/test_math.c with basic test cases for edge cases (max/min values, zero, negative)
• [ ] Update Makefile with optional 'test' target to compile and run test_math.c

• Add a TCP/IP network backend in parallel with the ipx/ modules—create tcpnet.c and tcpnet.h mirroring IPXNET.C/H to allow modern internet play instead of IPX-only LAN.
• Extract magic numbers from d_main.c and g_game.c into named constants in doomdef.h (e.g., GAME_TICKRATE=35, SCREEN_WIDTH=320, FRAG_LIMIT=20)—improves readability and makes balancing changes obvious.
• Document the BSP tree rendering algorithm with inline comments in the unnamed rendering code (README acknowledges the 'rendering proceded from walls to floors to sprites')—identify and annotate the wall/floor/sprite pass functions in d_main.c.

• High · Potential Buffer Overflow in Network Code — ipx/DOOMNET.C, ipx/IPXNET.C, ipx/IPXSETUP.C. The IPX networking implementation (ipx/DOOMNET.C, ipx/IPXNET.C) handles network packets and data structures. Legacy C code from this era commonly exhibits buffer overflow vulnerabilities due to unsafe string operations and fixed-size buffers without bounds checking. Fix: Conduct thorough code review of all network packet handling code. Implement bounds checking for all buffer operations. Use safe string functions (strlcpy, snprintf). Consider fuzzing network input handlers.
• High · Unsafe Memory Operations in Legacy C Code — linuxdoom-1.10/d_net.c, linuxdoom-1.10/i_net.c, linuxdoom-1.10/p_map.c. The codebase contains numerous C files (d_net.c, i_net.c, p_map.c, etc.) from 1990s-era code that predates modern memory safety practices. Common vulnerabilities include unchecked pointer dereferences, manual memory management without proper validation, and lack of input validation. Fix: Implement comprehensive input validation. Add pointer NULL checks before dereference. Consider AddressSanitizer (ASan) during compilation. Perform static analysis with tools like Clang Static Analyzer or Coverity.
• High · Hardcoded Configuration and Potential Information Disclosure — linuxdoom-1.10/doomdef.c, linuxdoom-1.10/doomstat.c, ipx/IPXSETUP.C. Legacy game code may contain hardcoded IP addresses, ports, or debug information. Files like doomdef.c, doomstat.c, and network configuration files could expose network topology or debugging capabilities. Fix: Audit all network configuration for hardcoded values. Remove or externalize any sensitive configuration. Disable debug output in production builds. Use configuration files for network settings.
• Medium · No Input Validation on Game Commands — linuxdoom-1.10/d_net.c, linuxdoom-1.10/g_game.c. Game command processing in d_net.c and g_game.c may not properly validate player input, potentially allowing malicious game packets to cause crashes or unexpected behavior. Fix: Implement strict validation for all network-received game commands. Add sanity checks on game state parameters. Implement checksums or CRCs for network packets.
• Medium · Insecure Random Number Generation — linuxdoom-1.10/m_random.c, linuxdoom-1.10/m_random.h. The m_random.c file implements custom random number generation. Legacy pseudo-random implementations are cryptographically weak and predictable, potentially exploitable in multiplayer scenarios. Fix: If randomness is used for any security-sensitive operations, use proper cryptographic RNG (e.g., /dev/urandom). For gameplay, document that the RNG is non-cryptographic and intentional.
• Medium · Use of Deprecated System Calls — linuxdoom-1.10/i_system.c, linuxdoom-1.10/i_video.c, linuxdoom-1.10/i_sound.c. Linux-specific code in i_system.c, i_video.c, and i_sound.c may use deprecated or unsafe system calls. Code from this era predates modern POSIX standards. Fix: Update system calls to modern POSIX standards. Review signal handlers for async-unsafe operations. Migrate away from deprecated X11/audio APIs. Use modern alternatives like SDL or ALSA.
• Medium · No Authentication or Authorization in Multiplayer — linuxdoom-1.10/d_net.c, linuxdoom-1.10/i_net.c, ipx/DOOMNET.C. The network code (d_net.c, i_net.c, ipx/) implements multiplayer without any authentication mechanism. Any peer can claim to be any player. Fix: Implement player authentication if hosting online games. Consider using cryptographic signatures for game state. For standalone/LAN play, document the security limitations.
• undefined · undefined — undefined. undefined Fix: undefined

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.