Fallacies of Doom Lessons learned from porting Doom 3 to Java
summary
A full Doom 3 C++ engine compiles and runs in Java as djoom3 after about three years of porting, but with many deliberate workarounds: unsigned ints become longs, const semantics are manual, pointers become one-element arrays, and unions that took months to untangle are reimplemented. Performance surprises include Java build times dropping to ~30–60s versus minutes for C++, and debugging traps like a duplicate ByteBuffer endianness bug that warped colors. Conditional breakpoints measure roughly 180× slower in hotspots; the port is functional but still buggy.
AI-written summary · about
chapters (14)
- 0:00Intro
- 0:33Boring intro: history
- 8:29Immutability, const vs final
- 11:59Unsigned primitives
- 14:00Operator overloading
- 18:56Destructor
- 20:31Grandfather inheritance
- 27:15Hungarian Camels
- 31:23Unholy union
- 32:39Default arguments
- 35:26The memory watcher
- 40:22Floating point operator precedence
- 42:27Conditional breakpoints
- 44:02A backwards compatible story?
related talks
01h 04mFallacies of Doom - Lessons learned from porting Doom 3 to Java
24mFrom C to Ruby: Porting Doom
29mHow I Ported Doom to the Browser with WebAssembly
56mFrom Hell to Heaven: Porting Doom to MAUI
23mDOOM Postmortem: 30 Years of DOOM
46mJava as a better C
49mCoding video game as a hobby, possible and (kinda) easy with Java!
55mBare metal Java