Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
IMX

A couple of questions about DOOM's source code release

Recommended Posts

If I'm not mistaken, once Dec. 27th arrives it will be 19 years since John Carmack uploaded DOOM's source code for the world to have and see.

So the other day I was wondering, how things were before the release, modding and user-made content wise? I can imagine it made things a lot easier, but how much we're talking about here? Was it a ground-breaking event to have the game source directly from id software, or was it just a small occurrence compared to the knowledge about DOOM modding that the community had at the time?

I am aware that, without source code, there certainly wouldn't be source ports, and that there were some pretty ingenious attempts to mod the game using hexadecimal editing, but did it also helped to understand mapping a little bit better and create better mapping programs?

Do you think that the DOOM community would have acquired the knowledge it possess right now anyway if there were no source code in hand?

EDIT: December 23, sorry!

Share this post


Link to post

You ask like 5 slightly different questions so it's hard to know what exactly you're asking about. If you're asking how much people knew about the Doom engine, the short answer is that they knew basically everything, even before the source code was released. You can peruse http://www.gamers.org/dhs/helpdocs/dmsp1666.html to see how much about the WAD format and so forth was known. I can't think of any major vanilla tricks that were only discovered after the source code release. There's some minor things like tall sprites (as rediscovered for Selfie Doom), some stuff about the movement code (like elastic collisions, which I finally tracked down in the Doom Movement Bible), and nonsense like linguortals, but in general, mapping for vanilla in 2016 is essentially identical to mapping for vanilla in 1996 in terms of knowledge of how the game works.

In terms of "modding" and not just mapping, DeHackEd was the state of the art then, as it pretty much is today. I am sure nowadays someone could, with the help of the source code and IDA Pro or similar disassembler, create a "super-Dehacked" that would allow users to change much more than was figured out back then, but no one has bothered to do this, so it's hard to say. The closest thing would be Doom-plus, which is a hacked vanilla EXE with greatly raised limits. Before the source code release, this would have been an incredible boon, and I'm pretty sure no one would ever have figured it out without the source code to help guide them.

Share this post


Link to post
Linguica said:

...I am sure nowadays someone could, with the help of the source code and IDA Pro or similar disassembler, create a "super-Dehacked" that would allow users to change much more than was figured out back then, but no one has bothered to do this, so it's hard to say...

Heh, I'm working on something like that, which will be released before too long. I don't know how helpful it will be nowadays with all the source ports out there, but it's a fun project.

A few things came to light after the source release. Check out the Boom development notes, and specifically the work of Lee Killough. One of the biggest finds was on what visplanes were and how they worked. Another find was exactly what the Medusa effect was, and the creation of code that fixed Medusa once and for all.

Share this post


Link to post

Eternity has expanded MBF's dehacked with extra code pointers etc. But no other port implemented those and Eternity also has EDF, so it's kinda useless.

Doom Retro has expanded MBF's dehacked in a different way, adding more "room" basically. That's why my SMOOTHED mod was possible but noone else followed with these simple additions. Literally a few lines of code to unshackle dehacked modding without reducing compatibility ... but noooo.

Share this post


Link to post

I still will never understand why Boom didn't unshackle BEX from having a fixed number of states in the state table, and instead just let it have an arbitrary number.

Share this post


Link to post

There was this alternate engine that could play Doom and Heretic:
https://www.samba.org/dumb/
https://web.archive.org/web/19991009002734/http://stekt.oulu.fi/%7Etosi/dumb/dumb.html
The source code is still out there, but probably won't build after 20 years of compiler and environment changes.
https://ftp.samba.org/pub/dumb/
README.dumb says project was started in 1995, and based on this code:
http://www.ibiblio.org/pub/Linux/games/arcade/wt-0.05.lsm
http://www.ibiblio.org/pub/Linux/games/arcade/wt-0.05.tar.gz

Share this post


Link to post
Linguica said:

I still will never understand why Boom didn't unshackle BEX from having a fixed number of states in the state table, and instead just let it have an arbitrary number.

Apparently making these tables dynamic was hard, so you had ports like Fusion that just went with "let's add a thousand dummy states and mobj types". Unfortunately for them, by the time they appeared, there was DOSDoom with DDF.

Share this post


Link to post
hex11 said:

There was this alternate engine that could play Doom and Heretic:
https://www.samba.org/dumb/

Yeah, I helped a bit with its development.

From memory it did not use the BSP tree, just your classic wall-sorting algorithm inherited from WT (which I also played around with at the time). And I think flats were rendered in the obvious but slow way of just drawing each column (doing the perspective calc for each pixel).

Share this post


Link to post
kb1 said:

Heh, I'm working on something like that, which will be released before too long. I don't know how helpful it will be nowadays with all the source ports out there, but it's a fun project.


I'll believe that when I see it :)

but I think it's a blind alley these days. IMHO the best dehacked (and ACS) killer would be an embedded JS or Lua engine and lots of the tables (if not lots of the game logic) in the doom source converted over to JS or Lua tables and accessible to modders that way.

Linguica said:

I still will never understand why Boom didn't unshackle BEX from having a fixed number of states in the state table, and instead just let it have an arbitrary number.


I'd like to think that by not doing so, they kept some pressure on the community to create a better long-term solution (like I argue for above) but it hasn't actually happened so erm, oh.

Share this post


Link to post

Yeah, I would like all game logic to be converted to a high level language like python and the user can replace functions and add/hook new ones. Did that pyDoom effort get anywhere before discontinuation?

Share this post


Link to post
kb1 said:

Heh, I'm working on something like that, which will be released before too long. I don't know how helpful it will be nowadays with all the source ports out there, but it's a fun project.

Jon said:

I'll believe that when I see it :)

You'll believe what? That I'm working on it? That it'll be released? Or that it is fun? Heh.

It's an extension of my decompiling efforts, mainly for demo compatibility checking, and for curiosity. It started out as support of a single game mod, but I hate to write hard-coded stuff, so I figured - Why not make it a real, extensible, useful general tool? I'll release it. It's kinda cool in that, it reads the exe details and list of offsets from a text file, so you can add support for your own offsets, or even different exes by editing the config file. Finding the offsets requires some hex editing and disassembly, though, so I'll periodically add support for more exes and more exe offsets as I discover them. It's a silly little app that I devote effort to, as time permits.

Jon said:

...but I think it's a blind alley these days. IMHO the best dehacked (and ACS) killer would be an embedded JS or Lua engine and lots of the tables (if not lots of the game logic) in the doom source converted over to JS or Lua tables and accessible to modders that way.

I'd like to think that by not doing so, they kept some pressure on the community to create a better long-term solution (like I argue for above) but it hasn't actually happened so erm, oh.

I've wanted some of the port devs to get together to discuss the possibility of a cross-port solution, without a lot of success. Actually, it looks like DECORATE format could be a candidate. Problem is, it's a big leap to support customization, as well as the ability to add - something that DeHacked lacks.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×