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

[Gez]

In the nineties there was still a pretty big demoscene, as well as things like obfuscated code contests and "esoteric" languages. So there was this whole subculture for which cool code was code that was excessively clever in how it worked. By "excessively clever", I mean both code that is hyper-optimized to get more performances than generally thought possible out of the hardware of the era, at the price of using very strange kludges; or code that was deliberately made hard to understand so as to get the admiration of their peers if they thought up of something that they found challenging to understand. Unreadable code was either a mean to an end, or the end itself.

[Graf Zahl]

at the price of using very strange kludges;

Actually, you can still find that thing in EDuke32...

[Apeirogon]

Also, why anybody dont uses something like

Code: Select all

double/float closest_square_root(double/float number = 0)
{
	if(number <= 0) return 0;
	int root = 0;
	int rooter = 1;
	while(true)
	{
		if(number < rooter) break;
		number -= rooter;
		root += 1;
		rooter += 2;
	}
	return root;
}

this method to get exact integer root before using it in newton/babylonian/etc method? Adding/subtracting is much faster than multiplication/division, no?!
That too much mathemagic for 90-s programmers? Or that too much for i486? It do (root) amount of steps to find perfect integer root of a number.

Reason
1 = 1

1 3 = 4
3 3

1 3 5
3 3 5 = 9
5 5 5

1 3 5 7
3 3 5 7 = 16
5 5 5 7
7 7 7 7

[Graf Zahl]

What do you want with an integer root of a number? That's perfectly worthless in all cases where you need a square root.

[Phredreeke]

M210 has added software renderer to the beta build of BuildGDX. I made a video running the game's first demo on both BloodGDX and NBlood to compare the performance

[Graf Zahl]

Is the 2.5x performance difference just the Java penalty?

What screen size did you play this on, btw?

[Phredreeke]

640x480 windowed. This was recorded on a i5-3450 running Windows 7. NBlood is a 64-bit build, while BloodGDX is running on 64-bit OpenJDK 12 (same version bundled with BuildGDX 1.03)

I can't say if the performance penalty was purely from Java or whether NBlood had any additional optimisations. I also noticed afterwards that I left the crosshair and kill/secrets counter on for BloodGDX but I doubt it would have a meaningful impact.

[Teddipetzi]

After playing a few Duke Nukem 3D mods I couldn't help but notice that it's all on a relatively small scale. Yes, there's a few features not normally seen in Doom mapping but overall it never really reaches the scope being achieved in Doom projects. Even vanilla mods like BTSX seem bigger, not to mention what gets made for Boom - and the more notable ZDoom projects, like Paranoid, Winter's Fury, ZDCMP2 or even the already 14 year old KDiZD (wow, where did all the time go...) vastly eclipse anything I have seen being made for Duke or any of the other Build games.

Is this due to some engine limitation or just a case of Doom being easier to develop for?

[Gez]

Both, I think.

[drfrag]

Doom was a much better game than Duck Nuked 3D and way more successful.

[Graf Zahl]

Definitely both.

A few things to consider:

Build depends even more on global variables than Doom's original software renderer. Wiorse, it often uses global variables to pass data between functions. That means that some limits are extremely low, e.g. IIRC it got a limit of 16384 lines, not sure if it's linedefs or sidedefs, but in any case this is a lot less than what many modern Doom maps contain.
All this global data makes it extremely hard to scale the engine - increase one limit and you got a domino effect that requires upping other limits which may often incur performance penalties.
The render algorithm is also a lot less performant and reaches its limits a lot easier than Doom's BSP.
The worst aspect of Duke Nukem (from what I have seen, Blood and Shadow Warrior are built in a somewhat saner fashion) is that it is all centered around the concept of Tiles. A tile is a texture, a tile represents the type of an actor, it represents what a floor or wall is or what not. And to top ot off, a tile is just a number, meaning you got a shitload of code that has zero structure, it's endless switch/case blocks to differentiate between types of entities. Trying to extend the system is impossible - and since everything is tied to texture indices the entire code is like a house of cards when considering add-ons - you have to move in a far more rigid framework than even Dehacked allows. That numbered tile system is actually Build's undoing if you ask me, it's the antithesis of modding friendliness.
In addition, the technicalities of the engine filter right through to the mapping process, unlike Doom, where they are sufficiently abstracted behind texture names or linedef action types. The few numbers the user has to remember are all in separate namespaces, i.e. a thing number has completely separate meaning than a line action or a sector type. The entire concept of sector effectors and other things a mapper has to be aware of requires a far steeper learning curve.

And let's not forget the biggest problem of the Build community: Their editors are utter garbage. Mapster32 which is being distributed with EDuke32 has the look and feel of a DOS graphics application being run in a window. It has no good UI and UX is shit - so this most likely explains why the community is so much smaller. It's like the pinnacle of Doom editing was still DETH/ZETH.

And while the Build engine originally far eclipsed the Doom engine in terms of features, compared to GZDoom there's really only one thing left it can do which GZDoom can't, and that is movable sectors. Everything else can be done in some form - be it 3D floors or portals or even sector teleports (which were directly inspired by Duke3D anyway.) I've even seen a remake of Lunatic Fringe being made for Eternity - the map also works in GZDoom, btw.

Doom was a much better game than Duck Nuked 3D and way more successful.

Now that was some truly helpful information we really needed...

[drfrag]

Third reason. BTW i really liked ZETH.

[Graf Zahl]

And still, "I didn't like the game" is not an objective reason for anything's success or failure.

The technical aspects of the engine are. I have spent some time trying to dig into that Build code over the last few days but saying that I didn't get deep would be an understatement. Thanks to that overuse of global variables it is utterly impossible to analyze the information flow. Everything operates on the same variables and trying to isolate parts of the engine results in weird errors, apparently because they need some information that got set somewhere far away.

All things said, I would say it is a technical impossibility to design a more modding friendly port for Duke Nukem 3D and its offspring (as there are Nam, WW2 GI, Redneck Rampage and Ion Fury) and that technical impossibility simply means that, unlike Boom and ZDoom have done, extended game features are very hard, if not impossible to add.

[PlayerLin]

About Mapster32(it's just BUILD editor with EDuke32 things in it)...
Duke community also have such "arguments" not too long ago, but in the end, since no active devs have time/interest to invest better editor(someone did 11-14 years ago, too bad it was written by VB6 and canceled long time ago), and Mapster32 is "worked as intended"(and known BUILD engine/Duke3D mappers used this "Bible" when mapping...), so...unlike DooM, seems passed so many years, still no others want to spend time to make a better editor for Duke/Build engine at all, sadly to say.

Not sure about why nothing happens for code mess of EDuke32(can't remember I see any of discussions or happened on somewhere I never go to, not sure), but...maybe same thing(s) applies, have no enough time/better man-powers to do the refactor jobs or/and afraid things going apart in progress to make the Duke community suffers even more I guess. After all, Build Engine(and the Duke3D code) is a huge beast for sure... *sigh*
The guy who working on EDuke32's C/S architecture also suffered the code mess(both Build Engine and Duke3D) too so that's why IF still have only single-player campaign when released, that's all the sign -- it's not a easy job to get done.

[Graf Zahl]

From my own experience I can say that cleaning up a rotten code base is one of the hardest tasks a programmer can face. Over the last two weeks I have been trying to figure out why EDuke32 performs so badly when VSync is enabled in the polymost renderer, but the way the engine is written with OpenGL system calls spread out everywhere it is extremely time consuming.

I was able to locate the primary cause - but it cannot be everything - otherwise GZDoom would show the same issues, but it doesn't. So there must be something else, but with such scattered code it's going to be quite a bit of work to find the trigger for the performance problem. I tried to start several refactorings to narrow down the target surface that needs to be investigated, but each and every time I ran afoul of Build's mess of global variables. The sad conclusion is that Build is not refactorable - it so much depends on dirty coding and side effects from using global variables that if you remove one brick, the entire building comes crumbling down.

So a cynical thought: Calling this engine "Build" is false advertisement - it should have been called "Demolition" because it inevitably destroys any sane code that comes in touch with it...