fraggle Posted March 30, 2008 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. 1 Share this post Link to post
Csonicgo Posted March 30, 2008 Reminds me of Strife's Animated doors. possibly the same concept. 0 Share this post Link to post
RestlessRodent Posted March 30, 2008 Yeah, I saw code for sliding doors in the Doom Source and wondered why it was all commented out. 0 Share this post Link to post
EarthQuake Posted March 30, 2008 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? 0 Share this post Link to post
GreyGhost Posted March 30, 2008 I'm imagining someone using these doors in a DM wad and letting their victims find out the hard way. :-) 0 Share this post Link to post
deathbringer Posted March 30, 2008 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 0 Share this post Link to post
CODOR Posted March 30, 2008 Is there some way of making the animation smoother by playing with X-offsets and adding transparent areas within the engine? 0 Share this post Link to post
LogicDeLuxe Posted March 30, 2008 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. 0 Share this post Link to post
geekmarine Posted March 30, 2008 Any chance of de-bugifying it and having it be fully functional (and not hideous)? 0 Share this post Link to post
BJ Blazkowicz Posted March 30, 2008 Isn't just a simple frame animation? 0 Share this post Link to post
_bruce_ Posted March 30, 2008 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. 0 Share this post Link to post
printz Posted March 31, 2008 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. 0 Share this post Link to post
esselfortium Posted March 31, 2008 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! 0 Share this post Link to post
Xeriphas1994 Posted April 1, 2008 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. 0 Share this post Link to post
myk Posted April 2, 2008 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. 0 Share this post Link to post
printz Posted April 2, 2008 fraggle said:A Chocolate Doom patch that re-enables the codeI`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. 0 Share this post Link to post
esselfortium Posted April 2, 2008 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. 0 Share this post Link to post
Graf Zahl Posted April 2, 2008 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. 0 Share this post Link to post
Quasar Posted April 2, 2008 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. 0 Share this post Link to post
esselfortium Posted April 2, 2008 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 0 Share this post Link to post
Graf Zahl Posted April 2, 2008 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. 0 Share this post Link to post
deathbringer Posted April 2, 2008 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 0 Share this post Link to post
printz Posted April 2, 2008 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? 0 Share this post Link to post
esselfortium Posted April 2, 2008 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... 0 Share this post Link to post
TheDarkArchon Posted April 3, 2008 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. 0 Share this post Link to post
Creaphis Posted April 3, 2008 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 0 Share this post Link to post
printz Posted April 3, 2008 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. 0 Share this post Link to post
esselfortium Posted April 3, 2008 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. 0 Share this post Link to post