ZDoom vs. BUILD?

Is there anything BUILD can do that ZDoom still can't emulate in some fashion? Could a painstaking level editor remake BUILD levels/items/weapons/actors in ZDoom and lose nothing in the translation? Or are there still some advantages to BUILD designing that ZDoom can't offer to level authors?

BUILD still has a few tricks up its sleeve that would be tough to do in ZDoom. Not as much as you might expect, though.

Do note that the Shadow Warrior engine is the most advanced incarnation of the BUILD engine though and had a shitload more stuff added to it than you get in the stock codebase. Or at least that's always been my understanding.

Mithran Denizen said:

BUILD still has a few tricks up its sleeve that would be tough to do in ZDoom. Not as much as you might expect, though.

Wow, the terrain movement/deformation stuff is crazy.

Quasar's certainly right that Shadow Warrior is much more advanced than the plain 'Duke3D' version of BUILD, though even that has the non-static slope movement and some nifty moving sectors / sector-over-sector stuff, among a few other features that ZDoom can't really handle.

I think Shadow Warrior is still fit as a BUILD comparison to ZDoom, though, because it's the most feature-rich of the games that used the engine as a base, plus the source code is now available (and I think it actually has been since like 2006 or something).

Not that I wouldn't give my left kidney to see Blood working properly through something other than DOSBox. :)

The only thing Build is not as good as Doom is in handling large open levels. I once tried adding a Build-style sector processing algorithm to GZDoom. It worked ok but performance completely broke down on wide open levels. For those Doom's BSP is still much better.

Thanks to the lack of BSP, you can move every wall in real time, though. No need for very limited polyobjs. The only restriction is, that you can not cross other sector boundaries. Also, sectors can overlap as you like, as long they can not be seen simultaneously. Only RORdoom had this ability. Overlapping sectors can even share the same altitude, which is not possible in any bsp based 3D engine.

I wonder, would it be possible to do some kind of hybrid renderer? At least 90% of a typical Duke3D map could be done in Doom with bsp, especially the outdoor parts. Maybe a sector flag to exclude it from the bsp tree and the engine should portal render them automatically then. Wouldn't this give us the benefits of both?
An intelligent node builder could detect automatically any moving or overlapping sector to set this flag accordingly.

I think this would be doable but it's obviously a lot of work to get it to work properly. The biggest issue is that the renderer would have to switch back to the BSP behind the BUILDified area and doing this properly is the biggest issue in my opinion. It wouldn't work without a lot of help by the node builder which would have to treat the entire area containing any BUILD-like structure as one large subsector.

Maybe someone should make a doom port based on the build engine?

If someone was going to put two renderers into a port it would be cooler if they were wildly different, like in Descent 3. Imagine outdoor areas in Doom using a Magic Carpet style renderer...

Marnetmar said:

Maybe someone should make a doom port based on the build engine?

That would actually be pretty interesting. Is there anything the Doom engine can do that Build can't? I can't really think of anything.

Graf Zahl said:

The only thing Build is not as good as Doom is in handling large open levels. I once tried adding a Build-style sector processing algorithm to GZDoom. It worked ok but performance completely broke down on wide open levels. For those Doom's BSP is still much better.

I don't see why it isn't. Most of Duke3D's city levels are quite large. It's not like performance is much of a factor nowadays anyway since any modern PC runs Duke3D at like 500fps.

I think Graf was particularly referring to modern maps. Good luck running Vela Pax, Blackrock, or Deus Vult 2 at a playable rate without BSP. :P

Doom is more complicated than you think. For one, software rendering isn't easy, but BUILD shares that handicap so it's not really relevant. However, BSP allows Doom to support huge maps without chopping them into parts and only loading one at a time, or using more complicated tricks like procedural generation. Without that stuff, you're faced with the daunting task of collision detection and occlusion over thousands and thousands of sectors. Doing this even at the low rate of 35fps is pretty intense, and really the only way Doom gets away with it is using BSP.

It's easy to say, "Pff, Doom/BUILD is so primitive compared to Black Ops or Bad Company, surely there will never be performance issues", but in many ways Doom's technical achievements still dwarf modern games. The vast majority of advances that have been made are graphics-oriented and implemented in hardware. But when you start talking about game logic, collision detection, or physics in general, we're basically still at Doom/BUILD technical levels, with all the limitations that suggests.

Well, it's also perhaps worth mentioning that tons of engine limits have been lifted from the original Doom source code by heroic source port authors, so it's not as if something written in 1992 could magically handle modern maps like Sunder. In many ways Doom has kept current with hardware advances, so it's probably more accurate to say that while Doom's renderer is arguably a lot more primitive than that of modern games, source port engine updates continue to take advantage of hardware advances (more RAM, bigger/faster disk drives, faster CPUs).

esselfortium said:

I think Graf was particularly referring to modern maps. Good luck running Vela Pax, Blackrock, or Deus Vult 2 at a playable rate without BSP. :P

The one I used for testing was Hellcore 2 MAP09 (Hobb's End Horror)

This is a wide open city map with absolutely nothing view blocking in sight and the time the Build algorithm needed to sort the geometry was utterly prohibitive. With a BSP you don't need to sort. That's what the BSP is there for, after all.

Duke's city maps are tiny by today's mapping standards for advanced Doom source ports.

If I was picking an engine to make a 2.5D game with from scratch, I'd definitely pick Eternity Engine. I can add features myself if I really need them, so the arguable pros and cons of ZDoom and Build are outweighed by the fact that it has a real FOSS license. ZDoom's/Build's licenses can bite you down the road if it's a serious project.

Ladna said:

It's easy to say, "Pff, Doom/BUILD is so primitive compared to Black Ops or Bad Company, surely there will never be performance issues", but in many ways Doom's technical achievements still dwarf modern games. The vast majority of advances that have been made are graphics-oriented and implemented in hardware. But when you start talking about game logic, collision detection, or physics in general, we're basically still at Doom/BUILD technical levels, with all the limitations that suggests.

I think the real limitations are caused by the fact that most games still have static levels at their core, even if individual objects are destructible, or even parts of the level are, like in Red Faction. In this sense Minecraft is arguably the most ground-breaking 3D game since Doom, since it's the first commercially-successful 3D game where 100% of the level is completely dynamic.

Spleen said:

If I was picking an engine to make a 2.5D game with from scratch, I'd definitely pick Eternity Engine.

But... The curse, man! What about the curse?

Gez said:

But... The curse, man! What about the curse?

The curse that the codebase is stable?????

Maybe the curse of eternal development? :D

Csonicgo said:

The curse that the codebase is stable?????

It was of course a joke about how none of the ambitious projects for Eternity ever come to fruition. (The real explanation being naturally that the majority of ambitious projects tend to be abandoned before completion, and EE has had just a handful of them so it's statistically normal that none of them were ever released.)

Not sure what you mean by "stable codebase" though. Ever since I started compiling its SVN builds, I've seen it go through several development branch merges, thorough rewrite of many subsystems, and a complete switch from C to C++. Before my time, FraggleScript support has been entirely removed and now Small is starting to go this way as well. The codebase seems to have a healthy amount of mobility; which makes sense for a program in active development.

It was cool watching those SW videos, I never knew the Build engine could do things like that, but it makes sense since it isn't limited to the BSP.

Marnetmar said:

Maybe someone should make a doom port based on the build engine?

Someone was doing exactly this but I forget who. Read every thread in Source Ports started within the last two years and you might find out.

Creaphis said:

Someone was doing exactly this but I forget who. Read every thread in Source Ports started within the last two years and you might find out.

Sounds a lot like Hellduke TC.