Learning about the Doom Engine

Hi there, good people.

About two or three months ago, I decided I wanted to learn how exactly the Doom engine works. What's behind Doom's behavior, glithces, bugs, etc. Where should I begin? I think maybe learning some C, since (I think, not sure) it's the language in which the Doom engine was written? I want to really understand how this whole thing works, I want to get deeper.

What should I do?

EDIT: I wanted to post this in Doom General, very sorry, I don't know what I was thinking.

1. Study doomwiki, get started here, here, here and here.
2. Learn C, from whereever you want - there are free tutorials on the internet for sure.
3. Find a download for the Doom source code and feel free to dive into its guts (examine the particular .c and .h files, what, how and why they do).

I've actually been toying with the idea of starting a blog or something where I go through the Doom source code and examine / explaining various aspects of it, so I approve of this urge.

Anyways, yeah, Doom was written in C. My suggestion would be to download MSVC++ and a port like Chocolate Doom or PrBoom so you can make little changes and see how they affect things. (Which actually reminds me of another thing I want to do, namely, write a beginners' guide to setting up MSVC++ for editing / compiling a source port.)

I think messing with the Doom source code would be a great way to get familiar with some relatively simple coding, and I wish it was a little more user-friendly to get involved with.

scifista42 said:

1. Study doomwiki, get started here, here, here and here.
2. Learn C, from whereever you want - there are free tutorials on the internet for sure.
3. Find a download for the Doom source code and feel free to dive into its guts (examine the particular .c and .h files, what, how and why they do).

In addition to these, another good resource to look at would be Fabien Sanglard's site, in particular this article on the Doom software renderer (as used in the iPhone port, but it's still the same software algorithm).

Definitively, try studying Doom's source code. Better yet, try making your own source port. Perhaps the absolutely best way to improve yourself in not one, but two languages AND learn about the Doom engine, is to port Doom into another (non-C/C++) language.

Maes said:

Perhaps the absolutely best way to improve yourself in not one, but two languages AND learn about the Doom engine, is to port Doom into another (non-C/C++) language.

Since Maes has already ported Doom to Java, I humbly suggest that the next step be porting Doom to Java2K.

Gez said:

Since Maes has already ported Doom to Java, I humbly suggest that the next step be porting Doom to Java2K.

I might as well finally implement DEH support and allow running The Sky May Be, then ;-)

how much math is there to understand the doom engine? I understand the gist of pre-calculus and am pretty good with college level algebra. is that good enough?

It's mostly computational geometry and basic math -but with the twist that there are no floating point operations: everything is done in fixed-point math masquerading as regular integer math and LUTs, which may take some time to get used to.

Programming is a different thing that math (although not hating math helps a lot when learning programming). You need to get to understand the principle of programming, the particular programming language (in this case, C) and its possibilities. As a programmer, you need to think a certain way, which might be natural to some people and hardly comprehensible to others. I personally didn't find it hard at all to learn basics of C++ almost entirely on my own when I was 15.

reality 2.0 said:

how much math is there to understand the doom engine? I understand the gist of pre-calculus and am pretty good with college level algebra. is that good enough?

I'd say so, yeah. A while back I reasoned out a part of the rendering code using nothing more advanced than high school algebra / trigonometry.

Sorry for the little bump, but I'm not sure about something. I wasn't sure if C and C++ are basically the same, so I googled it. It didn't help. Virtually all the answers/websites use technical language which I can't understand. So, straight to the point: should I learn C++ or just plain old C? And something else, should I learn something before learning either?

If you learn all of C++ then you will also learn (almost) everything of C. These days, there's no reason to limit yourself to learning just C.

C++ is C with more stuff tacked on it; most importantly classes.


Then there's a few subtle differences but they don't really matter much for a beginner.

Pretty much all of the classic C++ primers I've seen start off with teaching C, and then move on to specific C++ features, though some of the modern ones skip basic C (e.g. example programs use C++ namespaces and stream I/O rather than classic printf/scanf console I/O and read/write file I/O right away).

Yeah, do make sure you're learning from some relatively modern source material else you risk learning all manner of APIs and techniques that'll be largely irrelevant nowadays.

Generally speaking one learns how to program rather than the mechanices of a particular language.

At least in my experience, the older the source text the less likely it is that theory and language specifics are clearly separated.

DaniJ said:

Yeah, do make sure you're learning from some relatively modern source material else you risk learning all manner of APIs and techniques that'll be largely irrelevant nowadays.

In the case of C, I'd dare say that there are no irrelevant techniques: the language is mature, with many of its important features and libraries pretty much set in stone despite more recent revisions, plus there's a lot of existing code written using those conventions. It would be a handicap for a C++ programmer not being able to use the "classic" printf and read/write functions, IMO. OK, they are not the prime choice in pure C++ code, but they still do appear in many real-life situations, even projects which nominally use C++.

Under that aspect C is a much more stable language than e.g. Fortran, where the differences between "classic" standards such as 77 and the 90 and later ones can be dramatic, to the point that someone proficient only in Fortran 90 might not be able to produce even a single working "Hello World" program in Fortran 77, without reading up on the specs.

DaniJ said:

Generally speaking one learns how to program rather than the mechanices of a particular language.

Though in a mid level language like C, since you have to deal with the memory layout at some point, the mechanics of the language are also the mechanics of the machine, plus a valuable lesson on how digital computers work, as the functioning principles are (still) largely the same, unless some unforeseen innovation makes the Turing/Neumann architecture we're still using obsolete.

An example of how "just learning to program" without focusing at all on the mechanics and/or learning about basic computer architecture can be harmful: I once had a student proficient with LISP who however just couldn't understand the concept of "memory arrangement" for contiguous C arrays, aka it was incredibly hard/nearly impossible for him to understand how a "base address + index" access system could work, and thus understand cache locality, block copies, etc.. For him, everything should work like a LISP list, or nothing. For that matter, the very concept of "memory address" was inconceivable. "OK, so memory is like a bunch of numbered cells, called 'addresses'....and a list's head is stored in one address...but how does the compiler/computer know where the rest of the elements are?!"

DaniJ said:

At least in my experience, the older the source text the less likely it is that theory and language specifics are clearly separated.

That is true to a very large extent, perhaps because of a different teaching philosophy.

Either way, I don't think that going to an extreme separation of theory and practice (e.g. a pure algorithmic book without any actual code + a pure language reference book, without any algorithmic examples) is the way to go, unless one's goal is CS in a purely academic/mathematical setting.

I wouldn't recommend that you go spelunking in the doom source code as a first exercise in learning programming, you'll likely just find it very confusing. Start with the basics and work your way up to doom's level from nothing and you will be able to appreciate the code far better than if you trudge through it with a microscope and no knowledge of what each piece is doing.

Also it helps immensely to know how the engine works from the outside, like what the map format is, where the limits come from, etc. Check out the doom wiki and take a look at their bug pages, as those provide some hints to the way the game works.

EDIT: Also I'd honestly recommend if you have no experience that you pick up C in place of C++. It's got fewer features but it's a much better designed language imho. Plus I reject the idea that it's hard for beginners to pick up, because it was the first language I learned and I had no trouble with it at all.

Lastly... while porting the doom source to other languages will probably get you familiar with the codebase, it probably won't get you very familiar with how the 3D algorithms actually work. In my experience the best way to do that is to actually build an engine yourself - it's not hard if you know how and they are smaller projects than many beginners imagine.

Linguica said:

I've actually been toying with the idea of starting a blog or something where I go through the Doom source code and examine / explaining various aspects of it, so I approve of this urge.

I'd be interested in contributing, if there was not too much pressure to deliver on a schedule. It's something I have been wanting to do for a long time, complete with tons of illustrations, sound and video clips, etc.

kb1 said:

complete with tons of illustrations, sound and video clips, etc.

DO WANT to see them! :)