I've been having a look at the original DOOM source code, which id Software has
put on GitHub: https://github.com/id-Software/DOOM.
I wanted to see if I could follow their source code, and maybe find something neat for my bag of tricks.
I ended up succesfully porting the video output to a modern platform-independent OS window on 64-bit
My port of the original DOOM code (which no longer works on desktops) to modern windowed output.
Code Style Review
The first thing that strikes me is that it's in C, not C++, and actually the style and conventions are
almost exactly the same as those I've grown to prefer myself. They use C++ comments, with some blank
comment lines to emphasise headings for functions and things:
Otherwise it's pretty much GNU-standard style, which I think I saw John Carmack support in a tweet
somewhere. They even have GNU-standard Changelogs and Makefiles. The indentation is a bit messy - tabs are
always assumed to be equivalent to 8 spaces or something crap like that. I guess that's the default in
emacs or whatever they were using.
The really nice thing about this code is that it's bare-bones C. It has basically no external
dependencies on dated DOS libraries that are gone. If you want to write code that lasts do re-invent the
wheel, do not re-use code from others. There are some supporting utility functions however,
but that's all plain C and included in the source. Notable missing external libraries used, which are
absent for copyright reasons (Carmack notes in the README that he regrets using these):
Sound and music playback.
Video display (DOS and presumably the original Unix-based NeXT-Step one).
They've replaced these in the '90s with a woefully out-of date X server for linux, and woefully out-of-date
inadequate Linux sound system, neither of which will run on a modern system.
It's hard-coded to use 32-bit computing, and uses a lot of integer-pointer arithmetic. The problem with this
is that on a modern, 64-bit computer, it won't compile because the size of integers is still 32-bits but
the size of pointers has doubled to 64-bits. 64-bit pointers let us do wonderful things like address more than 4GB
of memory. The compiler is disgusted by any such 32-64 number comparisons. Integer/pointer comparisons are
not a great idea anyway, and these days we have some data types to abstract these problems.
There were a few bugs in the source which look like were errors introduced post-release to cope with the
third-party add-on episodes. The compiler found these, and it was easy to fix them. Mostly just a case of
strings for map names being longer than the allocated memory for the string. An incorrect system header for
error numbers was used - I just renamed that.
There are little scraps of assembler code inlined, which is pretty neat, and these seem to play well with
a GCC compile.
One neat trick that I found was a nice way to check all the command-line parameters for a particular
phrase. I always did this the hard way in a big nest of if-else clauses: