Stupid BSP Tricks

Csonicgo said:

I'm not one to bring up history, but the developers of BSP 1.x and DEU 5.x actually knew about this BSP behaviour during development and had plans to create a GUI for manipulating the BSP directly. If they had succeeded, this effect would likely be as common as any voodoo doll trick.

I don't think his tweet really supports your proposition that they knew about it.

Linguica said:

I don't think his tweet really supports your proposition that they knew about it.

Good point, it is more accurate to say that they likely would have discovered it immediately upon creating the GUI. I mean, once you see it graphically, it's kind of hard to avoid not seeing the potential of a hand-tweaked BSP tree.

I interpreted GUI as to mean something like DEU, rather than a tool for custom-crafting a NODES lump.

I already got a report and I still don't know anything about how this behaves in EE or why it wouldn't just work as-is.

esselfortium said:

ZDoom and GZDoom already support portals and have an extensive system for modifying maps at runtime, so if these could be detected then couldn't they be supported in ZDoom regardless of renderer by automatically flagging a couple of lines?

To be blunt, I'm not going to bother analyzing how this works. GZDoom never uses the original BSP for rendering and can't make use of any abusive hacks in that data. It requires a clean, well constructed BSP to work as intended.

I'd consider any such hack map broken by design and let their makers deal with the inevitable backlash. This also means that I won't bother with bug reports concerning such maps. If one ever materialized any report caused by a hacked BSP trick not working will be closed on sight.

Graf Zahl said:

I'd consider any such hack map broken by design and let their makers deal with the inevitable backlash.

Would you like some french fries to go with all that salt? Maybe some popcorn?

No problem; for ports which don't support this trick, you can use a placeholder texture with a mocking message.

EDIT:
* Doesn't this risk causing subsector traversing loops (and thus lock-ups)?
* Can you do an infinite (but curving, to avoid infinite loops) sequence?
* The only useful gameplay feature of this is cameras, so you can see what's going on far away.

I don't know why Graf is worried about maps using this, it is just a visual trick/illusion. You can't shoot or be shot through this. The maps will work just fine otherwise.

An author could also use ACS to fix it for zdoom I guess. It's really not a big deal, just a curiosity.

With that said, when is the inevitable Linguortal community project getting started?

Tarnsman said:

Would you like some french fries to go with all that salt? Maybe some popcorn?

And then i have the "asshole" title, tsk tsk.

Graf Zahl said:

To be blunt, I'm not going to bother analyzing how this works. GZDoom never uses the original BSP for rendering and can't make use of any abusive hacks in that data. It requires a clean, well constructed BSP to work as intended.

I'd consider any such hack map broken by design and let their makers deal with the inevitable backlash. This also means that I won't bother with bug reports concerning such maps. If one ever materialized any report caused by a hacked BSP trick not working will be closed on sight.

Always thinking about your users, eh? Gee, I can think of a lot of things that only work in ZDoom. As soon as I get a report mentioning that this Decorate code doesn't work in my port, that report will be closed on sight. Heh.


It should be easy enough to figure out why this doesn't work in some ports. Most assuredly, it's due to some simple optimization that could be made optional. If I get a chance, I'll check it out. Could be something as simple as Killough's slime trail fix, for example. The fact that it works in Mocha Doom is the most obvious clue.

As for the purists, wondering whether or not this effect should be supported in ports or not, I claim 'Yes', it should be supported. Here's why:

The nodes are user-supplied - they are part of the map format. Do ports support custom texture placement? Yes, because texture placement is part of the map data. Variable monster placement? Yep - thing placement is in the map data. Different-than-vanilla floor and ceiling heights, and images? Yep - in the map data. Reject tricks? Yes, because the Reject map is part of the map data. If a port author has decided to use some other, non-vanilla way to render a map, that produces results different than vanilla, on vanilla maps, then they have broken the renderer. Plain as that.

If the effect does not work in 3d accelerated ports, the translation to 3d rendering is incomplete. Plain as that.

Most all BSP tools build different nodes, and most all of those tools provide options for how the nodes are to be built. This is really no different.

Vanilla is the only real authority here, from which everything must be judged. If you can't render in a vanilla way, you're not rendering Doom - not completely.

kb1 said:

If the effect does not work in 3d accelerated ports, the translation to 3d rendering is incomplete. Plain as that.

Vanilla is the only real authority here, from which everything must be judged. If you can't render in a vanilla way, you're not rendering Doom - not completely.

A correct Doom visualization comes down to a correct render of the original commercial Iwad levels. The rendering bugs, hacks, glitches, and artifacts found and used by hobby mappers come second, yet they deserve to be implemented in at least one modern source port to not break the legacy of the hobby mappers.

When it comes to 3D accelerated ports with actual 3D architecture and a real perspective it seems that the programming needed to mimic 2.5D tricks becomes a real challenge... i can only imagine something as intersecting 3D models, weird portal like rendering to mimic the double view where sector are bleeding into sectors, etc...

Doom could also access whatever memory it wanted, write to NULL pointers, corrupt its heap in many cases without consequence, and just keep on running like a steamroller.

We do our best to advance the engine without dropping support for the weird garbage data that people generated as mods back in '94. You can't really anticipate people starting to abuse the data structures in new ways, though. That's why I initially expressed concern.

At some point you can have your cake OR eat it. I'm not sure if this kind of hackery is where that line is at or not - guess it depends on if anybody can figure out the real reason MBF-based ports choke on it or not.

If this could be implemented in a user-friendly mapping tool that would leave clearly recognizable evidence for modern ports to be able to recognize and emulate the portal, I would love to see it happen.

It's a genuinely useful effect that expands the known capabilities of the vanilla engine, so I'd consider it a bit different from a bug like accessing outside memory :)

kb1 said:

As soon as I get a report mentioning that this Decorate code doesn't work in my port, that report will be closed on sight. Heh.

Unless "DECORATE support" is part of your port's claimed features, then yeah of course you should. I don't see how this is supposed to be a burn.

As for these hacked portals, I'm waiting to see them used in a real level with a complicated node structure instead of a demo map with simplistic geometry.

printz said:

* Doesn't this risk causing subsector traversing loops (and thus lock-ups)?
* Can you do an infinite (but curving, to avoid infinite loops) sequence?
* The only useful gameplay feature of this is cameras, so you can see what's going on far away.

Yes, no, and no.

Quasar said:

guess it depends on if anybody can figure out the real reason MBF-based ports choke on it or not.

This is an extremely far fetched gues, you can laugh at my ignorance if needed. i am shit at math and C or C++

//
// RenderBSPNode
// Renders all subsectors below a given node,
//  traversing subtree recursively.
// Just call with BSP root.
//
// killough 5/2/98: reformatted, removed tail recursion

void R_RenderBSPNode(int bspnum)
{
  while (!(bspnum & NF_SUBSECTOR))  // Found a subsector?
    {
      node_t *bsp = &nodes[bspnum];

      // Decide which side the view point is on.
      int side = R_PointOnSide(viewx, viewy, bsp);

      // Recursively divide front space.
      R_RenderBSPNode(bsp->children[side]);

      // Possibly divide back space.

      if (!R_CheckBBox(bsp->bbox[side^=1]))
        return;

      bspnum = bsp->children[side];
    }
  

kb1 said:

If the effect does not work in 3d accelerated ports, the translation to 3d rendering is incomplete. Plain as that.

I mean, tricks that can be done without hex editing end up unsupported by 3D renderers due to not really working in a 3D environment, so this is kind of like saying plain bread is white and claiming it's not bread because it's not brown. Especially when it's been known that white bread is white.

... Heck, it's even named after it.

Graf Zahl's position is reasonable enough to be honest. I totally understand it.

It's still a cool hack though. I wonder if it's possible to come up with a modified version of BSP that will be able to support the most basic type of hack (this one) that seems to work in quite a few source ports.

fraggle said:

Graf Zahl's position is reasonable enough to be honest. I totally understand it.

I understand and respect his decision not to implement support for these sorts of tricks in his port. That's perfectly reasonable.

What I don't agree with is pouring scorn on the trick itself and trying to discourage anyone playing with this, as if (gz)doom was the only port that mattered.

Get real people.

This stuff will never move beyond the realm of tech demos, because in real life maps the node structure will quickly become far too complicated so you'd need some deep integration into the node builder so that it leaves the affected areas free of unwanted node splits - somewhat comparable to how ZDBSP can work around polyobject sectors, but on a far, far more complex scale. And of course you need a map editor so that it won't become a chore of hex-editing the finished map (which would get broken as soon as it was loaded into an editor again and re-saved.)

You'll need to find a programmer willing to invest this work, so here's the first questions: What node builder? Who will do it? Is there even a node builder left aside from ZDBSP that sees some active maintenance?

No, sorry, I feel no need to lose any sleep over this. It will remain an obscurity of the hard core of 'classic' Doomers and never move beyond that group because it's technically unfeasible to use in a real map.

@Jon: You seem to forget that even PrBoom features an OpenGL renderer that will never be able to support such tricks properly. And what about other hardware accelerate ports? No, it's not just the ZDoom-based ports you'd shut out, but far far more.

This stuff may be fun to play around with to see where one can go with it, but use it for real in a map? Quite unlikely.

Graf Zahl said:

You seem to forget that even PrBoom features an OpenGL renderer that will never be able to support such tricks properly. And what about other hardware accelerate ports? No, it's not just the ZDoom-based ports you'd shut out, but far far more.

Unfortunately, the same can be said about some "real" features. For example, good luck making complex colormap effects in your wad. At least we have fullbright support in GZDoom, most likely because this effect is used in Strife, a "legit" commercial game, and is trivial to detect and emulate. On the other hand, ZDoom doesn't seem to read Boom transparency tables, even though it's software.

It's a harsh reality of Doom modding. Use of any features beyond the most basic "mainstream" set will shrink your potential audience.

Graf Zahl said:

And of course you need a map editor so that it won't become a chore of hex-editing the finished map (which would get broken as soon as it was loaded into an editor again and re-saved.)

You'll need to find a programmer willing to invest this work, so here's the first questions: What node builder? Who will do it? Is there even a node builder left aside from ZDBSP that sees some active maintenance?

Yes. I outlined the structure of a tool that could make this a lot easier a few posts ago. I might even write it. I'd probably work from GLBSP.

No, sorry, I feel no need to lose any sleep over this.

Why should you lose sleep over this anyway? Thou dost protest too much. You keep repeating that this isn't important but why are you still here arguing if you feel that? You're trying to put people off exploring this for selfish reasons (so you aren't pestered by people wanting it to work in gzdoom). I can appreciate that would be annoying, but if you really believe this will remain an esoteric tech demo, why would you get a flood of such reports anyway?

Your attitude to me feels like "Zdoom is the only thing important in the doom community now" which is nonsense.

It will remain an obscurity of the hard core of 'classic' Doomers and never move beyond that group because it's technically unfeasible to use in a real map.

Most likely, yes. I don't see what's wrong with that. If you're looking down your nose at that group of enthusiasts from some kind of other doom community sub-group ivory tower then that's pretty hilarious.

@Jon: You seem to forget that even PrBoom features an OpenGL renderer that will never be able to support such tricks properly. And what about other hardware accelerate ports? No, it's not just the ZDoom-based ports you'd shut out, but far far more.

I'm not forgetting at all. It doesn't matter. Sure, gl-prboom(+) won't work; neither will (g)zdoom; at the moment neither does doom retro or crispy (although I imagine that might change). No doubt all ports that replace the renderer will not work. None of that makes it any less of a cool trick, technically. Even if it only worked in Vanilla (heck, especially if it only worked in Vanilla) it's neat.

If it works anywhere, and people want to spend time on it, they are free to do so.

This stuff may be fun to play around with to see where one can go with it, but use it for real in a map? Quite unlikely.

Personally, I don't care whether it makes it into a non-tech-demo map or not. I imagine it will make it into just one "real" map. But that still doesn't make it any less of a cool trick.

Da Werecat said:

It's a harsh reality of Doom modding. Use of any features beyond the most basic "mainstream" set will shrink your potential audience.

Only if your audience consists of people who refuse to use more than one port.

The interesting thing is that despite being called an "abusive hack", it works in what is probably the most "sterile" port of all.

Jon said:

Only if your audience consists of people who refuse to use more than one port.

Yes. But I'm sure there are enough people of habit who just don't bother.

Maes said:

The interesting thing is that despite being called an "abusive hack", it works in what is probably the most "sterile" port of all.

Do you mean chocolate doom? Don't ALL abusive hacks work in that?

VGA said:

Do you mean chocolate doom? Don't ALL abusive hacks work in that?

I meant Mocha Doom. It's not even written in C, and it doesn't have the liberty of fucking around with memory and dangling pointers (though it does emulate some types of overflows). However, for the most part, it's a literal C to Java translation, especially the purely numerical/logical code. Especially the BSP code was one of the most straightforward parts, which never required any hacks, and yet it worked with the portal feature as-is.

Jon said:

Only if your audience consists of people who refuse to use more than one port.

You have to make one crucial distinction here:

There's people who do not use certains port for behavioral changes. But if a mod is concerned that depends on these changes, that's hardly a justification not to use it.

On the other hand, if some 'feature' means leaving all advanced engines in the dust and having to play in 320x200 blur-o-vision (or even 640x400), you can pretty much count out 90% of your potential user base by default.
There's also the added problem that full resolution software rendering tends to become quite slow, which is one of the main reasons why people actually use hardware acceleration, because lower resolutions than the panel size look extremely bad on modern TFT monitors.

Maes said:

However, for the most part, it's a literal C to Java translation, especially the purely numerical/logical code. Especially the BSP code was one of the most straightforward parts, which never required any hacks, and yet it worked with the portal feature as-is.

Not really surprising as the effect is purely algorithmic and does not depend on something undefined.

Unfortunately it also depends on the rendering algorithm pretty much being untouched which leaves every port in the dust that tries to optimize here or use a different approach (and if it's just something as trivial as ZDoom's discarding of the redundant seg offsets.)

Jon said:

Yes. I outlined the structure of a tool that could make this a lot easier a few posts ago. I might even write it. I'd probably work from GLBSP.

That would be really cool!

I should mention, though, that since the effect is primarily for vanilla, it would be by far most useful to have it in ZenNode (my first choice, personally) or BSP-W32, which are both capable of optimizing for vanilla's rendering limits to a degree that other nodebuilders I've tried can't touch. Is there something in particular about GLBSP that makes it an appealing target for implementing this effect, though?

esselfortium said:

That would be really cool!

I should mention, though, that since the effect is primarily for vanilla, it would be by far most useful to have it in ZenNode (my first choice, personally) or BSP-W32, which are both capable of optimizing for vanilla's rendering limits to a degree that other nodebuilders I've tried can't touch. Is there something in particular about GLBSP that makes it an appealing target for implementing this effect, though?

Thanks for the tips. No, the only reason I'd start with GLBSP is because I know it's been touched recently-ish. I think I packaged it for Debian. The Vanilla-specific stuff in BSP and/or ZenNode would indeed make them better candidates.