Question regarding the source code for DOS vanilla Doom

[Porsche Monty]

Would something useful (or at least interesting) be revealed if the source code for DOS vanilla Doom were released? excluding the sound part of course.

[Csonicgo]

If I recall correctly, we have pretty much all that was there and even some that wasn't in the final (such as automap asteroids). Anything else that was used is possibly known from analysing the executable itself.

However, I would love to see the source code from various times of its development (more specifically, each version release). Alpha code would be fine, too.

[Searcher]

Are you looking for something like this?

http://www.google.com/search?q=doom-sourcecode&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a

[GreyGhost]

Porsche Monty said:

if[/b] the source code for DOS vanilla Doom were released?

Here you go - don't tell anyone who or where you got it from.

On a more serious note, fraggle found some unused sliding door code in the source.

[exp(x)]

Guys, that is not the DOS source code.

[wesleyjohnson]

The wad hth2.wad has horizontal sliding doors, and no I do not know how the author did it. It is a DoomLegacy wad and I suspect it is fragglescript. I think some horz. door commented out stuff is still in DoomLegacy too.

DoomWiki has some of the best info I have seen on doom versions and source code differences.

[Maes]

While converting the Doom source code for my own Java source port, I discovered some unused code for automap strobing, demonstrated here.

I can see why they didn't use it...it wasn't hard to reactivate though. Maybe I'll add it as a cheat or fraggle could enable it in Chocolate (which actually has it as dead code, while other ports eliminate it completely)

However, to answer your question, I recall that the original Boom team actually had access to undisclosed details of the DOS source code...so I suppose those aspects are reflected in some way in Boom derivatives, not pure Doom ones.

Plus, there are some mapping tricks, not entirely dissimilar from 3D bridges, that allow simulating sliding/hinging doors (with an equally ugly effect) in vanilla Doom.

[kristus]

wesleyjohnson said:

The wad hth2.wad has horizontal sliding doors, and no I do not know how the author did it.

This is actually a Boom effect being used. No scripting involved. It's quite clever. The door got lines on it to refer to the door mid textures. As the door is activated and move it's set up to scroll these leaf textures on each side of the door.

This effect is usable in any Boom compatible engine.

[D_GARG]

Ive heard somewere that its harder to make a "fake" 3D engine than making a "real" 3D engine. ( Doom isnt fully 3D ) ....


Any one knows if this is true?

[Quasar]

D_GARG said:

Ive heard somewere that its harder to make a "fake" 3D engine than making a "real" 3D engine. ( Doom isnt fully 3D ) ....

Any one knows if this is true?

To some degree, yes, and to others, no. DOOM's screenspace clipping nonsense is extremely complicated and it can take years to come to a full understanding of it.

On the other hand, true 3D engines have what I'd consider often insanely complicated movement clipping code which has to do all kinds of linear algebra, quaternion calculations, even calculus for physics, and all of that's necessary if you want realistic 3D environments.

So there are tradeoffs.

[Gez]

Doom definitely doesn't care about realistic environment. Even disregarding that it's not 3D. The way objects (and explosions!) are square, for example.

[DaniJ]

Quasar said:

DOOM's screenspace clipping nonsense...

I wouldn't call it nonsense. Complicated perhaps but certainly not nonsense. I happen to consider it a rather effective algorithm for the hardware of the time.

[Quasar]

DaniJ said:

I wouldn't call it nonsense. Complicated perhaps but certainly not nonsense. I happen to consider it a rather effective algorithm for the hardware of the time.

True. I just wish it didn't get so messy, especially with 2S lines.

[DaniJ]

I take it that screenspace clipping in Cardboard is effectively working the same way as vanilla DOOM (but rather than a rectangular screen you are clipping against 'portal envelope' geometry)?

[Quasar]

DaniJ said:

I take it that screenspace clipping in Cardboard is effectively working the same way as vanilla DOOM (but rather than a rectangular screen you are clipping against 'portal envelope' geometry)?

Pretty much, yes. For dealing with maskeds, in particular, there is a stack rather than the old set of globals.