4 ms·
Yet another random number generator that depends on global mutable state and therefore unsafe to be used in multithreaded context.
by netheril96 11y ago
Yet another random number generator that depends on global mutable state and therefore unsafe to be used in multithreaded context.
- pjc50 11y agoDOOM was, of course, single-threaded and built to run on the single-core CPUs of the time.
- netheril96 11y agoPeople 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.
- Tepix 11y agoYou do realize this code is around 20 years old?
- netheril96 11y agoI did not. Perhaps I was being too harsh to criticize this particular project.
- ionised 11y agoHave 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.
- pjc50 11y agoDoom 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).
- beastMartin 11y agoSometimes we forget it, I like to see old snippets of code, to learn or for curiosity.
- stcredzero 11y agoAs 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?"
- ralphw_oz 11y agoThat's truly sad. And ironic.
- fdej 11y agoThe 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.
- pjc50 11y agoIt's not crypto. It's a game. The whole thing is global mutable state. ( https://github.com/id-Software/DOOM/blob/master/linuxdoom-1.10/g_game.c 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.
- boomlinde 11y agoYou 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.