Why fastDOOM is fast

Original Article ↗ Hacker News Discussion ↗

Nostalgia and “Gear You Couldn’t Afford”

  • Several comments riff on the author’s “dream 486” with parallels to long-wanted camera gear and other expensive hardware from youth.
  • People emphasize that high-end gear isn’t “wasted” on amateurs; better ergonomics and responsiveness can meaningfully change how often you practice and improve.

Ken Silverman, Build Engine, and Hardcore 486 Tricks

  • The linked GitHub discussion with the Build/Duke3D author is widely praised: using obscure 386/486 registers, CR2/CR3 as scratchpads, and ESP as a loop counter are highlighted as mind-blowing micro-optimizations.
  • Build and Duke3D are remembered fondly as early, approachable FPS engines for scripting and modding, credited with starting some careers.

Playing Doom Today (Browser & Odd Platforms)

  • Multiple in-browser Doom options are mentioned (archive.org, js-dos, other web ports), plus novelty ports like “Doom in a PDF.”
  • FastDOOM itself is celebrated for enabling smooth play on very slow or vintage hardware and for quirky video modes (MDA text, EGA, CGA hacks, Hercules), even when they’re slower than VGA.

DOS-era Networking and Storage Over Network

  • mTCP’s NetDrive sparks a deep dive into historical network filesystems: Novell NetWare, SMB, AppleTalk/AppleShare, AFS, and early Unix/NT campus setups where home directories followed you.
  • Comments contrast those seamless 1990s shared-filesystem experiences with today’s mix of cloud silos and less cohesive desktop environments.

Why Make Doom Faster?

  • Answers range from “run on weaker/vintage hardware” and “save power” to “pure intellectual fun” and “geek cred.”
  • Some note that Doom is now a de facto benchmark/standard, so it naturally attracts ongoing optimization efforts.

Triple Buffering, VGA, and Mode Details

  • There’s a technical thread on how triple buffering reduces VBL waits on VGA: you can always render into a free page and switch display start addresses without tearing.
  • People discuss the existence and reliability of VGA VBL interrupts, polling the CRTC, and subtle details of page-flip timing.
  • Another subthread debates Mode Y vs 13h and VESA 2.0/linear frame buffer availability on specific 486-era hardware.

Profiling and Unexpected Bottlenecks

  • The article’s example—optimizing the status bar percentage rendering for a 2 FPS gain—is used to illustrate that bottlenecks often live in surprising UI details.
  • Many analogies appear: progress bars and spinners dragging down apps, JSON parsing in big games, CSS or SVG animations dominating CPU/GPU, logging and INI reads becoming hidden hot paths.

Modern Software Slowness and Tooling

  • Commenters argue that heavy abstraction (Electron, complex UI frameworks) plus lack of profiling leads to trivial features burning significant resources.
  • Others defend browsers and web stacks, noting that when used correctly (e.g., GIF vs poorly-designed CSS animations), they can be highly optimized.
  • There’s a broader observation: when software is exploratory and fast-changing, “fast enough” often beats deep optimization; once something becomes a standard (like Doom ports, protocols, or engines), optimization gets serious.

Compilers, Assembly, and Porting FastDOOM

  • The article’s note about Watcom vs DJGPP performance leads to discussion of difficulty porting: build systems, compiler flags, and especially large amounts of x86 assembly (syntax and memory model differences).
  • People recall early-90s profiling tools (Watcom, MSVC, gprof) and debate how much systematic profiling was actually used in Doom’s era.

Design, Fonts, and Readability

  • The site’s minimalist, monospaced aesthetic gets attention; some love the “artistic” mono look, others argue monospaced fonts for prose are an anti-pattern and suggest system-ui or classic proportional fonts.
  • Text justification is briefly explained as simple CSS rather than a custom trick.

CPU Nostalgia and Accuracy Debates

  • There’s an extended side-discussion on 486 variants (DX, DX2, DX4, DX-50 vs DX2-66, SLC/SX confusion, 487 coprocessors), with corrections where recollections conflict with actual product history.
  • Stories of expensive 486 builds, early Linux dual-boot setups, and campus bragging rights over “fastest machine” echo the article’s hardware nostalgia.

Meta: Performance Testing Discipline

  • FastDOOM’s tight commit hygiene and frequent tagged releases are praised.
  • One commenter generalizes: regression-style performance testing (like the timedemo sweep in the article) should be treated as a first-class practice, not an afterthought.