gebbdoom: The TeX and Go Source Behind the Game Engine Black Book

A book released as source, not as a finished PDF

This repository is the source code for the Game Engine Black Book: Doom, and the primary language is TeX. That distinction matters more than it might sound. A PDF is a fixed artefact, whereas a repository of LaTeX source is something you can rebuild, patch and extend, and the author says so directly by releasing the .tex files under a GPL licence. The text is Fabien Sanglard's, and the accompanying drawings are handled separately: he retains ownership of all drawings and provides them only so that the overall thing is compilable. The repository top level reflects the structure of a book rather than of a program, with a `src/` directory for the LaTeX sources, a `fonts/` directory, a `cover/` directory, a `tools/` directory, and the two build entry points `make.sh` and `build.go`. The licence recorded in the repository metadata is unknown, so the GPL statement in the readme is the reference to work from.

Why a Go program drives a LaTeX build

The build is not a plain make invocation, which is unusual enough to explain. There is a `build.go` file at the root next to `make.sh`, and the readme asks for Go to be installed on macOS and for the golang-go package on Debian, even though the output is a PDF produced by pdflatex. That suggests the Go program is the orchestrator: it walks the sources, decides which figures to regenerate, and calls out to the external tools, with `make.sh` acting as the thin wrapper a user runs. The practical consequence for a reader is that the build needs two different toolchains working together, and that `./make.sh` is the single command that ties them together. The tools directory presumably holds the helpers the Go program drives, and the cover and fonts directories hold the assets that are not source text.

The toolchain a Linux reader needs

The Debian and Ubuntu instructions list what has to be present, and it is a single apt invocation that pulls in the whole TeX side of things.

sudo apt install inkscape texlive texlive-font-utils texlive-fonts-recommended texlive-latex-extra golang-go

The package list tells you what the book actually needs. TeX Live is the base distribution, the font packages cover the typography, texlive-latex-extra covers the LaTeX packages a book of this kind leans on, and Inkscape is there because the figures are vector graphics that have to be converted rather than typeset. golang-go is the build driver. Windows is handled by installing WSL1 or WSL2 and following the Linux instructions, which is a pragmatic answer that avoids a native Windows port of a toolchain that expects POSIX conventions.

macOS needs MacTeX, Inkscape and XQuartz

The macOS path is more involved, with three separate things to install. Go comes from its own site, and the readme points at the MacTeX library for epstopdf and pdflatex, installable either from the MacTeX download page or through Homebrew.

brew install --cask mactex

There is also a no-GUI variant for people who do not want the full distribution, and Inkscape needs a minimum version of 1.2.2, installable from the Inkscape site or through Homebrew.

brew install --cask xquartz inkscape

XQuartz is the interesting dependency in that line, because it is the X11 layer that Inkscape needs on macOS. There is a specific instruction to make sure the inkscape binary is in your PATH or to symlink it where your PATH points, which is the kind of detail that only surfaces when a build fails with a command not found. The final step on every platform is the same.

./make.sh

The debug flag and the cost of a full rebuild

Compiling a book of this size is slow, and the readme gives a concrete way to cut the time. Building with the debug flag uses 100 DPI assets instead of the full resolution ones.

./make.sh debug

The second suggestion is more hands-on but more effective for a focused edit: comment out the part you are not working on in `src/book.tex`. That tells you something about the structure of the book. It is a single main file that includes the chapters, so a partial build is a matter of trimming the include list rather than configuring the toolchain. That is a common pattern in LaTeX books and it is worth knowing before you spend an afternoon watching images convert. The debug mode and the trimming trick together are what make the repository practical to work in, rather than only to read.

What the repository does not include

There is no source code for the Doom engine here, no test suite and no issue tracker template, because this is a book rather than a program. The interesting scope question is what a reader can actually do with the source. The text is editable and the drawings are provided for compilability, but ownership of the drawings stays with the author, so the drawings are not the same kind of open content as the prose. The GPL statement covers the.tex source that is released, and anyone redistributing a modified build inherits the terms that apply to the text. That distinction between the licensed prose and the retained drawings is the one to keep in mind if you plan to fork and republish the volume.

Who this repository is actually for

The primary audience is a reader who wants the book as a working LaTeX project rather than as a fixed file. That covers several cases. A reader who spots a typo can fix it and rebuild. A reader working through the Doom engine source alongside the text can add their own notes or diagrams. A student learning how a long technical book is assembled can study the structure of `src/book.tex`, the font setup and the figure pipeline, which is arguably as instructive as the book itself. The toolchain cost is the barrier. Inkscape, a full TeX Live installation and Go are a heavy setup for someone who only wants to read about the Doom engine, and for that person the PDF remains the sensible route. The repository is for the people who want to change it.

Maintenance and the absence of releases

The repository is not archived and the last push was on 2026-09-10, so the source is still being touched. There are no GitHub releases, which for a LaTeX book is not a problem in the way it would be for a library, since there is nothing to depend on: you clone, install the toolchain and run the build. The `build.go` file is the piece most likely to need attention, since it is where the interaction with Go versions and TeX distributions is encoded, and the readme's instruction to install a specific Inkscape version and check the PATH suggests those interactions have bitten people before. A reader keeping a local fork of the book will find that the useful habit is to comment out what they are not editing in `src/book.tex` and to build with the debug flag until the text is settled.

Editorial conclusion

gebbdoom fits a reader who wants to rebuild the Game Engine Black Book from source, correct a passage or study how the volume is typeset, and who is willing to install a LaTeX toolchain and Inkscape. It is the wrong tool if you only want to read the book, since the PDF is the faster route, and the wrong tool for editing the prose alone, because the Go driver regenerates images and expects a full asset toolchain. Before you start, build with the debug flag to use the 100 DPI assets and check the compilation time on your machine.

Frequently asked questions

Official sources

1. fabiensanglard/gebbdoom on GitHub
2. Issues
3. README