Vanilla Doom sliding doors

Hi,

I got the Vanilla Doom sliding doors code working a couple of days ago. For those not in the know, this is some commented-out code that was included in the Doom source release, apparently intended for use in the Doom II Wolf3D levels, but never used. The effect is quite ugly (four frame animation) and there are also some bugs in places:



A Chocolate Doom patch that re-enables the code, along with a demo WAD, is here.

Preemptive response to inevitable question: No, this is not an April Fool's joke.

Share this post


Link to post

Reminds me of Strife's Animated doors. possibly the same concept.

Share this post


Link to post

Yeah, I saw code for sliding doors in the Doom Source and wondered why it was all commented out.

Share this post


Link to post

Do any sounds play? Or is there any sort of support for it playing sound? And do you plan on cleaning up the code to a point where it's use would be more practical?

Share this post


Link to post

I'm imagining someone using these doors in a DM wad and letting their victims find out the hard way. :-)

Share this post


Link to post

These are also in EDGE, where they work a little better (can't be shot through for instance), they are silent by default but can have sound added

Share this post


Link to post

Is there some way of making the animation smoother by playing with X-offsets and adding transparent areas within the engine?

Share this post


Link to post

This sure is interesting as a curiosity.

But if we want to overcome Vanilla Doom's functionality in serious mapping, we just use PolyObjects, don't we? Also, a fake Door should be possible with Boom's scrolling features.

Share this post


Link to post

Any chance of de-bugifying it and having it be fully functional (and not hideous)?

Share this post


Link to post

Good job fraggle.
But why has the door no depth - just a sprite?
Before I saw the vid, I assumed it was a sector "passing away" line per line.

Share this post


Link to post

Ugly may be, but it could have been used to create togglable Impassable linedefs, particularly grates, which for now are only permanent blockers.

Eternity has the 3dMidTex option, but it makes the affected linedefs block the projectiles as well as the actors.

Share this post


Link to post
printz said:

Ugly may be, but it could have been used to create togglable Impassable linedefs, particularly grates, which for now are only permanent blockers.

Eternity has the 3dMidTex option, but it makes the affected linedefs block the projectiles as well as the actors.


ZDoom can set lines impassible or impassible ingame with a script. Eternity might be able to do this too, I'm not sure.

Either way, the reasons why this is ugly and choppy and unfinished is because....it wasn't a finished feature! That's the entire reason why it wasn't in the final game in the first place!

Share this post


Link to post
fraggle said:

apparently intended for use in the Doom II Wolf3D levels

Inferno said:

Even weapons pass through it, lol.

As they did in the original DOS version of Wolfenstein.  The engine thought that doors opened and closed instantaneously, regardless of what their animations showed.

Share this post


Link to post

geekmarine said:
Any chance of de-bugifying it and having it be fully functional (and not hideous)?

I'd say the point was to more or less show the code that's already in the source, not to provide some OMG new feature.

LogicDeLuxe said:
But if we want to overcome Vanilla Doom's functionality in serious mapping, we just use PolyObjects, don't we?

That depends on the nature of the project, as the polyobjects code as seen in Hexen isn't free software.

Share this post


Link to post
fraggle said:

A Chocolate Doom patch that re-enables the code

I`m sorry, but ain`t Choco-Doom supposed to emulate vanilla Doom, not enhance it with map features? Next time we may see plain Doom wads actually requiring the port.

Post typed from a PSP.

Share this post


Link to post
printz said:

I`m sorry, but ain`t Choco-Doom supposed to emulate vanilla Doom, not enhance it with map features? Next time we may see plain Doom wads actually requiring the port.

Post typed from a PSP.

As you can see from the video, this isn't really usable as a map feature in its current form, and I doubt that it'll become a Chocolate Doom feature.

Share this post


Link to post
myk said:

That depends on the nature of the project, as the polyobjects code as seen in Hexen isn't free software.



The one in Eternity is. So there is an alternative for GPL ports.

Share this post


Link to post

Personally I don't think PolyObjects would work if you intended to use these things for every door in your map. For one thing, without an extension such as ExtraData, you are limited to 255 PolyObjects per map, due to the inability to address any more than that via the args to Hexen linedef specials and the angle field of mapthings. For another, the more PolyObjects you put in a map, the more likely you are to have trouble with overdraw errors and nodes getting split where you need square subsectors. Finally, the way PolyObjects are created is kind of annoying; requires a lot of extra, careful mapping work.

So with those things in mind, I don't think an extra way to do cheap, light-weight sliding doors would be out of line. I had considered resurrecting this code myself back when it was first (re)discovered, but I don't really have a solution for partial clipping, so that you could pass through the door as soon as it is open wide enough, and not either be required to wait until it is fully open, or be able to pass through it as soon as it is open even a crack. 3DMidTex do not solve this problem either, since they clip on a per-line basis and not a per-column basis.

Share this post


Link to post
Quasar said:

Personally I don't think PolyObjects would work if you intended to use these things for every door in your map. For one thing, without an extension such as ExtraData, you are limited to 255 PolyObjects per map, due to the inability to address any more than that via the args to Hexen linedef specials and the angle field of mapthings. For another, the more PolyObjects you put in a map, the more likely you are to have trouble with overdraw errors and nodes getting split where you need square subsectors. Finally, the way PolyObjects are created is kind of annoying; requires a lot of extra, careful mapping work.

So with those things in mind, I don't think an extra way to do cheap, light-weight sliding doors would be out of line. I had considered resurrecting this code myself back when it was first (re)discovered, but I don't really have a solution for partial clipping, so that you could pass through the door as soon as it is open wide enough, and not either be required to wait until it is fully open, or be able to pass through it as soon as it is open even a crack. 3DMidTex do not solve this problem either, since they clip on a per-line basis and not a per-column basis.

Heh, if there was some way to make horizontally-moving 3Dmidtex platforms, that'd be amazing. Silly annoying jump puzzles would never be the same again :P

Share this post


Link to post
Quasar said:

For another, the more PolyObjects you put in a map, the more likely you are to have trouble with overdraw errors and nodes getting split where you need square subsectors. Finally, the way PolyObjects are created is kind of annoying; requires a lot of extra, careful mapping work.



That's where polyobject-aware node builders come in.

Share this post


Link to post

You could make a crude emulation of a side-opening (not closing again) door using several instant-lower sectors. The advantage is it would be "3D", the disadvantage is it'd look more like the door was progressively dissapearing than 'opening'. Though it could work with more plain textures or if you see the actual opening from a long distance.
Using that method "swinging" doors work better, there's some in Eternal 3

Share this post


Link to post
Graf Zahl said:

That's where polyobject-aware node builders come in.

Are there any for Eternity, as long as it uses the Doom format?

Share this post


Link to post
deathbringer said:

You could make a crude emulation of a side-opening (not closing again) door using several instant-lower sectors. The advantage is it would be "3D", the disadvantage is it'd look more like the door was progressively dissapearing than 'opening'. Though it could work with more plain textures or if you see the actual opening from a long distance.
Using that method "swinging" doors work better, there's some in Eternal 3

It's tricky and extremely tedious/error-prone to build, but there is an actual way to do this without having the door look like it's "disappearing". The trick is to slightly angle the lines inwards by 1 unit. If you set it up right, it won't become progressively thinner as it opens, it'll just be 2 units thinner on one end than the other, which shouldn't be too noticeable. I made use of it in a map I did for a certain yet-to-be-released Boom project a while back...

Share this post


Link to post
printz said:

Are there any for Eternity, as long as it uses the Doom format?


Nodes are independant of the map format so ZDBSP and DeePSeas BSP(?) should be able to handle it.

Share this post


Link to post

There's also this sliding door method for Boom and compatible, but I don't know if it's worth using in any actual projects. It has the same clipping issue - when you can first enter the door, you can walk through the textured part of it.

http://www.doomworld.com/idgames/index.php?id=9714

Share this post


Link to post
TheDarkArchon said:

Nodes are independant of the map format so ZDBSP and DeePSeas BSP(?) should be able to handle it.

Fortunately EE uses the same doomednums for the polyobj things, so if the BSP prog doesn't care about map format, all's fine. It will be less fine if EE polyobjs are addressed through ExtraData control objects.

Share this post


Link to post
printz said:

Fortunately EE uses the same doomednums for the polyobj things, so if the BSP prog doesn't care about map format, all's fine. It will be less fine if EE polyobjs are addressed through ExtraData control objects.

I might be wrong, but I think the only way to use polyobjects in EE is with ExtraData control objects, as there are no fields for their id numbers or other parameters in the Doom map format. It might be possible to do them without ExtraData, but I've never done it.

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