Vanilla Doom sliding doors

[fraggle]

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.

[Csonicgo]

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

[RestlessRodent]

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

[EarthQuake]

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?

[Texas Libra]

That was ugly...

[Inferno]

Even weapons pass through it, lol.

[GreyGhost]

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

[deathbringer]

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

[CODOR]

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

[LogicDeLuxe]

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.

[geekmarine]

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

[BJ Blazkowicz]

Isn't just a simple frame animation?

[_bruce_]

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.

[printz]

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.

[esselfortium]

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!

[Xeriphas1994]

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.

[myk]

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.

[printz]

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.

[esselfortium]

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.

[Graf Zahl]

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.

[Quasar]

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.

[esselfortium]

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

[Graf Zahl]

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.

[deathbringer]

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

[printz]

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?

[esselfortium]

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...

[TheDarkArchon]

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.

[Creaphis]

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

[printz]

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.

[esselfortium]

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.