Hacker News Reader

Comment by pjc50 | Hacker News Reader

DOOM was, of course, single-threaded and built to run on the single-core CPUs of the time.

People should not get into the habit of depending on global mutable state. What if the project evolves and now going to work multithreaded? What if parts of the project are extracted to be used in another one? What if a toy project grows to be massive?

I say this because I have investigated many crypto libraries for usage and nearly every one of them (especially openssl) have random generators that depend on global state. The attitude of not caring about correctness and thread safety is just pervasive.

You do realize this code is around 20 years old?

I did not. Perhaps I was being too harsh to criticize this particular project.

Have you really never heard of DOOM or know how old it is?

I would have thought it was quite well known among the tech crowd, even non-gamers.

Doom was released in 1993. I'm guessing that netheril96 wasn't made until 3 years later.

Tech is a very ahistorical discipline. We don't look back at the "old masters". We reinvent things every generation (or in Javascript land, every week).

Sometimes we forget it, I like to see old snippets of code, to learn or for curiosity.

As Alan Kay said, Programming is "almost a field" because it forgets its own history. As the now-typical HN commenter says, "Who is Alan Kay?"

That's truly sad. And ironic.

The Doom engine uses a lot of global mutable state. In context, there's nothing wrong with this. Why pass around state explicitly when there's just one instance of the state? Multithreading wasn't on the horizon for game engines in 1993. Single CPU cycles were very much a concern. Developer time was also limited (most of this code was written by a single person in about a year). This wasn't a toy project that could have evolved in a million different ways, and it wasn't a crypto library either. There was a game that had to be shipped, and John Carmack was surely more concerned about getting the game engine to do precisely what it needed to do to run the game than proofing the code for hypothetical future scenarios.

It's not crypto. It's a game. The whole thing is global mutable state. ( https://github.com/id-Software/DOOM/blob/master/linuxdoom-1.... ). On the original DOS/4GW version, I don't think there were even any synchronisation primitives available.

DOOM was one of those games that relied on stretching the hardware to its limits to produce previously-unseen visual effects. The only thing that mattered was getting pixels on the screen as fast as possible.

Edit: no, of course there weren't any mutex primitives in DOS/4GW. It's a single-process single-thread bare metal environment. You have to realise that, in 1993 PC gaming, shared memory multithreading was simply not something that developers would ever encounter. It had no concievable advantages as you had only one CPU, not even a graphics accelerator. Games generally wouldn't multitask either; again, this predates consumer availability of Win32 and certainly is several years before DirectX.

You wouldn't use the Doom PRNG for crypto as much as you shouldn't use a spoon to cut down a tree. Have fun eating cereals with a chainsaw.

Reply on news.ycombinator.com