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

[Gez]

That reminds me, ZDuke was never resurrected from the Great Mancunet Purge.

[Graf Zahl]

I don't think much was lost there. It was a very basic port of the original DN3D code with no support for anything advanced. Now, if this had been an attempt at providing a thoroughly cleaned up code base à la ZDoom, it would have been regrettable but that wasn't the case.

[MartinHowe]

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.

Oh my ${DEITY}, yes. In my first job after my MSc degree, I spent years adding features to code my predecessor wrote for some our customers ... code written pretty much like Build; loads of global variables ... comment? what's a comment? ... and impenetrable variable names ... tint1 (temporary integer 1) was a favourite LOL. It took many months and some very patient clients to eventually to get into his coding style, maintain/kludge/bodge it like that, then later refactor it into something usable.

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...

ROFL

[Phredreeke]

BuildGDX 1.04 is now officially released

Besides the software renderer, the most significant change IMO is improved gamepad support. Been playing Blood and Redneck Rampage Rides Again with it on my GPD Win.

[Apeirogon]

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

To use it in more precise square root finding algorithm.
All root finding algorithms have around square speed of convergent, or something like that. Dont know how correctly translate this term to english.
In other words, the more close "guess" to actual root algorithm have the faster it converge to actual root. And with integer root, which literally smaller than actual root less than one, after calculation it return value with doubled amount of correct digits.

For example root of 123456 is aprox. 351.363060095. Integer root is 351, so first iteration of newton method gives
0.5 *(351 + (123456 / 351) ) = 0.5 *(351 + 351.726495726) = 0.5 * 702.726495726 = 351.363247863
which differs from actual root on 0.000187768, which is less than 0.00005 percent error.
Second iteration gives value which differs from actual on 1E-10 percents, which is more than enough for any practical usage.

Or it still too slow for this?

[Graf Zahl]

These days it's really no longer efficient to do such things, unless you need really huge numbers of square roots calculated.
While we are at that, I find it really funny how some programmers go out of their way to waste endless time and effort on such peephole optimizations while writing pathetically poor algorithms. If they did it the other way around, the result would always be magnitudes better.

[Apeirogon]

These days it's really no longer efficient to do such things

Processors become fast enough or what?

These days it's really no longer efficient to do such things, unless you need really huge numbers of square roots calculated.

But videogames are part of programming here you need much of roots, no?!

[Phredreeke]

I found this old blogpost that compares using x87, Carmack's algorithm and SSE for square root. https://web.archive.org/web/20091019133 ... uare-root/

[Graf Zahl]

These days it's really no longer efficient to do such things

Processors become fast enough or what?

These days it's really no longer efficient to do such things, unless you need really huge numbers of square roots calculated.

But videogames are part of programming here you need much of roots, no?!

You totally overestimate the amount of square roots that are needed. In general the only thing where you need them is distance calculations and in many cases you can get arounf the aquare root by comparing squares of distances. But even if not, we are talking about a few 100 square roots per game tic, amounting to less than a microsecond of calculation time.

Of course there's still those games programmers around who take a totally wrong approach towards efficiency, getting totally hooked on these peephole optimizations but then ending up writing monstrous code that performs like shit because it cannot be algorithmically optimized due to its style. The Build engine is a textbook case of such code.

One thing I frequently see is programmers eschewing C++ container classes like vector or string because they are "inefficient" and instead prefer to use static arrays or other constructs that avoid the perceived-as-inefficient allocations but offer no benefit because the code doesn't execute often enough.

I found this old blogpost that compares using x87, Carmack's algorithm and SSE for square root. https://web.archive.org/web/20091019133 ... uare-root/

While certainly interesting my point about square roots not frequent enough to really matter still stands. Those who get hung up on such mostly inconsequential things tend to neglect the reall opportunities for optimization. In GZDoom the few square roots being taken in the renderer make no difference whatsoever, by far the biggest problem it faces isn't suboptimal code but cache stalls.

[Phredreeke]

Reason I posted that was that it shows that using SSE is actually faster than Carmack's fast inverse sqrt. So even if you needed a lot of square roots it would still be faster doing it that way (but I assume if you needed a lot of them, you would be doing them on the GPU?)

[dpJudas]

Context is everything. Unlike the early 90's square roots are not time consuming to calculate for the majority of use cases anymore. For example, softpoly executes a sqrt for every pixel when it applies dynamic light. At 1920x1080 that's 2 million sqrts over 200 times per second - a total of over 400 million sqrts using no further optimization than the SSE isqrt instruction.

Like Graf says, use the standard library and aim for code readability for the majority of code. Then optimize the critical loops of the program and pick your data structures carefully for those loops. The rest is counterproductive and only makes things harder to maintain.

[Jblade]

There is/was a lot of large scale projects for Duke3D, the engine might be a cluster fuck but modding it is extremely easy and you only need to look at MSDN to see that there's tons of stuff out for it. I'll easily concede that Mapster isn't really fit for newer mappers though, we've got a few people learning it easily enough in the AMC TC discord but it's definitely not a pick up and play kind of thing like the newer Doom level editors are.

[Kizoky]

eDuke32 supports a maximum of 4096 sectors, 16384 walls and sprites

That's a really low amount compared to GZDoom's

[Graf Zahl]

But what's a wall? Is that a linedef or a sidedef in Doom terms?

Just FYI, a map like Frozen time renders over 13000 lines in one single scene (still managing 60 fps on a Core i7-3770 with a Geforce 1060) and the largest ZDoom map I know of has over 100000 linedefs.
16384 linedefs is being exceeded even by some vanilla maps these days.

No kidding, but with 16000 linedefs one could just create a static mesh of the map and flush it out in one go, without ever bothering to do all the Polymost projection and transformation stuff, and would probably still be faster on anything that's not a toaster.

[Jblade]

eDuke32 supports a maximum of 4096 sectors, 16384 walls and sprites

That's a really low amount compared to GZDoom's

low is a bit disingenuous though because you can still make massive single maps in Duke, even without using the hub system. The beach CBP or CBP8 are good examples of big maps that are still pretty well detailed. The limit is extremely generous; it's not something that's ever really constricted what I needed to do, and if it did than branching off into another map isn't an issue either. I've played ZDCBP2 which is HUGE and a single map and Adventures of Square ep2 has some massive impressive maps too so I understand that Gzdoom has very high limits, but it's never been a dealbreaker or a big problem in any of the duke projects I've worked on.

But what's a wall? Is that a linedef or a sidedef in Doom terms?

I'm not fully up to speed on all the technical workings of build, but I guess it's like a linedef?