Can a GZDoom-like engine be made for Build games?

[Graf Zahl]

I have never delved too much into the technical stuff of the Build engine, but from what I have read online:

1. There isn't as much documentation on mapping for the Build engine as there is for id tech 1. And some of the documentation that does exist have a high chance of being outdated.

2. If you're wanting to make something, you'd be better off making it for id tech 1. Not only is software for it more up-to-date than software for the Build engine, it's also a lot easier to use.

The biggest problem with Build had always been that strict separation between the actual render engine and the game logic - mapping for Duke Nukem and its family of games requires a somewhat different skill than mapping for Blood, for example. The biggest flaw in my eyes is that unlike Doom it doesn't identify textures by name but by index, and thanks to being built around static arrays its limits are a lot harder to break - you can extend them to a certain degree, but that'll mean the engine needs to allocate enough memory to hold the largest possible map allowed and also potentially increase processing time when the limits get bumped.

But the render engine is only one part - when I looked at the original Duke 3D source I couldn't really believe how primitive and rough it all was - sure, it got its CON scripts but the parser for those is one of the most hackish parsers I have ever seen in production code - and the rest of the game isn't really much better. The Build engine itself is even worse. And all things considered, none of the source ports ever managed to break free from the confines.
Like I already said, EDuke32 heaped feature upon feature upon feature onto that construct without ever thinking about refactoring that construct.

Despite the Doom engine being 2 years older, the id programmers were really years ahead in code maintenance skills, and had their engine enjoyed a few more years of shelf life I think it would have easily progressed beyond Build which had its upper ceiling of where it could reach due to its internal design. Even now you can't even think of making maps as large as some of the monstrosities made for GZDoom - a ZDCMP2 would make Build explode because it goes beyond all its limits.

As for banding NukeYKT (NBlood dev) came up with a way to interpolate between multiple shade table entries as to remove it.

That's the obvious solution for reducing the effect, but it's still a degrading palette to palette mapping that loses increasing color precision with each level.

[crazyflyingdonut]

But the render engine is only one part - when I looked at the original Duke 3D source I couldn't really believe how primitive and rough it all was - sure, it got its CON scripts but the parser for those is one of the most hackish parsers I have ever seen in production code - and the rest of the game isn't really much better. The Build engine itself is even worse. And all things considered, none of the source ports ever managed to break free from the confines.

I think this is the reason why some people didn't even bother with modding for Duke Nukem 3D, despite the fact that 3D Realms tried to add all the tools people could use for doing so.

I played some of the more popular Duke3D mods, a lot of them aren't that good. I really liked DNF2013, though.

[Graf Zahl]

I haven't been too much into Duke3D mods - it's just that I've become a bit bored of the recent output for Doom - aside from Eviternity and a handful of single map releases it was just lots of run-of-the-mill maps, most inside vanilla limits. So far I've been more busy with getting an engine set up to work to my liking than playing actual mods, though...

[Graf Zahl]

EDIT: I think I am getting closer to the cause of the problem here: When transitioning to shaders they of course looked into the option to approximate the software renderer's lighting - but unlike GZDoom, where this was done with a full precision shader operating on true color input they apparently went back to the source, paletted textures and lookup tables and all - and at some point - unsurprisingly their aging OpenGL 1.x renderer could no longer coexist with those changes. I managed to graft 6 weeks of changes onto the version before they decided to cut off the ties so far - let's see how far I can get. As long as it doesn't involve fundamental rendering changes it should be ok - the further I can get the better.

I finally managed to re-enable the old lighting mode with the current code base - altogether it was changing a mere 33 lines of code! It was all still there, just disabled and due to being disabled the engine got 3 otherwise minor changes that broke that 'classic' EDuke32 look.

[Apeirogon]

I remember I read once article where compared doom, DOOM not (g)zdoom/prboom/boom/etc, and build engine and there was this line "so in general doom was written by regular programmer, while build engine was written by a genius. This means that doom was written in the way that any human being with decent coding skill can understand it, here renderer, here monster logic, here map stuff. And build engine can be understand only by genius, because all important stuff in it dumped in a bunch, here renderer, after two lines monster logic, then again renderer, than map stuff, wait wait wait, we dont finis with monsters, etc. Plus there are a LOT of magic numbers and unobvious switches."

So main problem here to actually understand what silverman mean by numbers and what this code meant to do. I mean, there are no "default" code base which can be used by anyone to make iron maiden like game, without spending half of the year to realize what silverman mean by number 2 in this particular place.

[Graf Zahl]

It's not quite that bad but you got very close to the essence of it.
The different parts of logic are actually separated - the problem lies elsewhere - here's a good example, I'm not sure if it was by Silverman himself or by some of the follow-up programmers working with his code:

Code: Select all

    do
    {
        int32_t zz = z+1; if (zz == n) zz = 0;
        float const x1 = pxy[z].x, x2 = pxy[zz].x-x1;
        if (((float)cx1 <= x1) && (x1 <= (float)cx2)) { px2[nn] = x1; py2[nn] = pxy[z].y; nn++; }
        float fx = (float)(x2 <= 0 ? cx2 : cx1); d = fx-x1;
        if ((d < x2) != (d < 0)) { px2[nn] = fx; py2[nn] = (pxy[zz].y-pxy[z].y)*d/x2 + pxy[z].y; nn++; }
        fx = (float)(x2 <= 0 ? cx1 : cx2); d = fx-x1;
        if ((d < x2) != (d < 0)) { px2[nn] = fx; py2[nn] = (pxy[zz].y-pxy[z].y)*d/x2 + pxy[z].y; nn++; }
        z = zz;
    }
    while (z);

This is a perfect example how nearly all of Build looks. Cryptic variables, no comments, magic numbers and every other thing any novice programmer is being told to avoid.

There's really no doubt that Ken Silverman is a genius - it's really too sad that he lacked the common sense to make his code readable.
The irony is that the Doom engine ultimately proved far more scalable due to its cleaner design. It had some limits but they were imposed by the hardware of its time - but never directly impacted the engine's internal workings or performance. With Build this is different. The hard coded limits impact everything, the entire code is written around static arrays. Increase their size and you eat more memory and you may get a speed hit from all the iterations over these fixed size arrays. You can pretty much forget about an UDMF equivalent for Build - the map format's features are too tightly tied into the engine's implementation instead of being an abstract representation of what a level consists of.

Maybe it was just that the Build engine never attracted a programmer who is radical enough to toss out the old to reimplement it in a more approachable fashion. To work with this code I think one's thought patterns have to be in sync with Ken Silverman and such a person won't find much wrong with this coding style and most likely continue in the same way.

But be it as it may - if I had to hire a programmer, I'd prefer the regular guy with a clean coding style over the genius living on a different plane of existence any day when it comes to working together on a project.

[dpJudas]

And build engine can be understand only by genius, because all important stuff in it dumped in a bunch, here renderer, after two lines monster logic, then again renderer, than map stuff, wait wait wait, we dont finis with monsters, etc. Plus there are a LOT of magic numbers and unobvious switches."

No, poor software design doesn't make Ken Silverman a genius (*). The key difference between Doom and Build is experience and age. Silverman was a teenager essentially doing things way over his head. John Carmack was a guy that had already done many games and had experience working in a team. It really makes all the difference.

*) One can of course always debate if a teenager even able to what he did at his age makes him a genius, but that doesn't mean he didn't have most of the shortcomings of an extremely young and green developer. His early success may even have fucked him in later life as most teenagers don't react well to the attention of all the haters that comes with success.

[Graf Zahl]

Ken Silverman WAS a genius. The ideas he had for the engine were absolutely groundbreaking - and despite his shortcomings as a programmer he managed to pull it off. You got to give him credit for that.
What Silverman was NOT is a good programmer - quite the contrary in fact. The Build engine is one of the lousiest hacks I have ever seen, the code is just an atrocity. It's really too bad that all this obtuseness prevented a clean reimplementation of his concepts with a friendlier license.

Do I need to mention a certain piece of voxel code...?

[dpJudas]

I'll give him credit if people remember the entire story, where you include the fact that he had an actively involved dad and also spoke to Carmack and others way older than himself. It also depends on what one considers a genius anyway - the term is highly subjective.

Also, if someone is so highly intelligent then how can they fail so badly on the software design side of things? Whatever the case might be for Ken Silverman, he's obviously very talented - just to be clear I'm not questioning that.

[Apeirogon]

poor software design doesn't make Ken Silverman a genius

Implementation details.
Would you think of doing same rendering model as in build engine, draw sector with player first than sectors neighbor to that sector, that sector neighbor to sector sectors, etc?
Carmack spend almost year learning graph theory to make bsp tree implementation, while silverman came up with a much simpler idea. So simple that anyone no one could come up with the same idea.

[dpJudas]

You keep pretending like he lived in a vacuum. When the first 3D games came out there was a lot of material out there explaining how to draw it - i.e. my older brother (still teenager at the time) had his own written assembly code that could draw Wolfenstein 3D style graphics less than half a year after that game out (that'd be roughly about the time Ken's Labyrinth showed up I'd guess). Duke Nukem 3D came out two years after Doom, where every other kid of the teenagers that was into programming had at least heard about BSP trees and how Doom did it.

So that leaves what? Portals based instead of BSP, which Descent also essentially did at roughly the same time. Now don't get me wrong - that he pulled it off as a teenager was mighty impressive, but none of us is really able to tell how much he was assisted (i.e. feeding him the books and articles I've already mentioned).

[Graf Zahl]

Also, if someone is so highly intelligent then how can they fail so badly on the software design side of things?

Maybe for the same reason that highly intelligent people can be socially inept? His entire code strongly hints at very mathematical thought processes which is not the norm for most people. And this permeates the entire engine design, from how resources are organized to how actions are being expressed as map elements. Nothing of this was in any way Human friendly..

You keep pretending like he lived in a vacuum. When the first 3D games came out there was a lot of material out there explaining how to draw it - i.e. my older brother (still teenager at the time) had his own written assembly code that could draw Wolfenstein 3D style graphics less than half a year after that game out (that'd be roughly about the time Ken's Labyrinth showed up I'd guess). Duke Nukem 3D came out two years after Doom, where every other kid of the teenagers that was into programming had at least heard about BSP trees and how Doom did it.

Let's be realistic here: Yes, Duke Nukem came out two years after Doom, but what does that mean about the engine? The game couldn't really be developed without some basics already working, so ideally I'd give him one year on Doom's release to have something presentable.

So that leaves what? Portals based instead of BSP, which Descent also essentially did at roughly the same time. Now don't get me wrong - that he pulled it off as a teenager was mighty impressive, but none of us is really able to tell how much he was assisted (i.e. feeding him the books and articles I've already mentioned).

I read that stuff myself, most was about raycasting engines like Wolfenstein at that time, i.e. a type of engine nobody cared about anymore after Doom.

[Apeirogon]

So that leaves what?

That silverman in 1994/5/6 did what he did basing on his own experience and conclusions how to do this good.
Did he do it good from the perspective of a programmer from 1994/5/6? No.
Did he do it good from the nowadays perspective? No.
Did he do it good at all? You know answer.

And after all that, did results of his work have some popularity? Nuked duke, warow shadiow, bloob, red neck ram page, iron maiden....ehhhhh.....

[dpJudas]

Let's be realistic here: Yes, Duke Nukem came out two years after Doom, but what does that mean about the engine? The game couldn't really be developed without some basics already working, so ideally I'd give him one year on Doom's release to have something presentable.

There is 1 year between Wolf3D (1992) and Doom (1993). So clearly at the time you could write an engine within a year. Based on Descent's source code it was started in 1993 and released in 1995 - so once again one year for the engine, one year for the game. I don't know the release date for Ken's Labyrinth, but clearly by that point he had figured out the column/span rendering trick - which is half the secret. Only other part really is painter's algorithm and the clipper.

I read that stuff myself, most was about raycasting engines like Wolfenstein at that time, i.e. a type of engine nobody cared about anymore after Doom.

Sure, but it allowed everyone to become familiar with the principle of texture rasterization. The moment Doom came out it was less than half a year that there would be detailed explanations for its BSP algorithm. The one Ken didn't implement I might add - he went for a simpler and better solutions (portals). Just like Descent apparently did in the same time period.

As far as I'm concerned, the only thing arguing for him being particular genius compared to the competition at the time was his young age. Unless you consider all those other people be geniuses, in which that case I agree that Ken Silverman was too.

@Apeirogon: how do you know he did it based solely on his own experience. [citation needed] and all that. What's next? That we say John Carmack invented the BSP? (he didn't, but he was the first to apply it to a game)

[Enjay]

If I had to pick who I think is just the most talented, it would probably be Ken Silverman, the guy that did the Build engine. He does engines and tools. He writes all the code for everything, and he's just extremely talented.

Speaking of timings:

Ken started work on the Build engine sometime before his first semester at Brown University in 1993, under a contract with Apogee Software.

It all started late in 1993, several months after Apogee and Id Software released Wolfenstein 3D to the world