[Master O]

I know it's old news by now, but what do you guys think about this?

https://forum.zdoom....hp?f=12&t=67139

[Zaxx]

Nah, as far as I know this will be based on EDuke32 stuff and the point where it could benefit from the advantages of GZDoom is very far off. So "new Build Engine being developed" is entirely false but it could end up being "GZBuild" sometime in the future.

But here's how Graf Zahl put it when he was asked about the point of all this:

Quote

Why? Why not? I started with this because I had problems getting VSync to work properly in EDuke and because I wanted true color rendering back and a better music system than the Windows system MIDI synth. I tried BuildGDX but had other problems with that (e.g. the Java backend not recognizing all keys on my keyboard - and its VSync also did not work) From that I just went on, ending up changing more and more until I was able to plug the entire GZDoom backend into it.

You may ask the same question about the retro Doom ports. We already have PrBoom - do we really need Crispy and Retro? Apparently their developers have fun doing it. Shouldn't that be enough?

Anyway this will be interesting to see:

Quote

Actually, I ripped out all OpenGL code from Polymost, there is nothing left from the GL 1.1 code path and even less from the "modern GL" code path. This part is entirely new code, as is the texture manager. To be clear: There is not a single line of OpenGL accessing code left from EDuke. I also completely rewrote the shader it uses for rendering on modern hardware.

[NightFright]

"New" is indeed misleading, it's just yet another Blood port. In general it's good the game gets so much attention these days, but 1) BloodGDX is already my port of choice and 2) I am missing love for Shadow Warrior.

[Zaxx]

Yeah, me too but it will have support for SW and Ion Fury too so it's coming (just like SW is coming to EDuke32) and apart from the Capstone games it will be a "complete Build package". Overall it's just cool that there are alternatives if you want to play some Build games and well, it's Graf Zahl so you know he'll do good work that can help the Build community in a number of ways.

[Radar]

Zaxx, on 02 February 2020 - 07:52 AM, said:

it's Graf Zahl so you know he'll do good work that can help the Build community in a number of ways.

[CITATION NEEDED]

[Master O]

Radar 100 Watts, on 02 February 2020 - 09:55 AM, said:

[CITATION NEEDED]

https://zdoom.org/downloads

https://github.com/c.../commits/master

[NightFright]

We've been waiting for a port being able to handle all the important Build games for far too long, it's about time.

Stuff like Tek War can be ignored, Capstone games were nothing more like utter garbage, anyway. Civvie's Tek War video is all you need to watch. No coherent game design to be found there at all. But it was enough for a few good jokes about the most ridiculous aspects.

[Fox]

I'm looking forward to it.

Graf has way too much free time, and can do massive amounts of programming.

Quote

a better music system than the Windows system MIDI synth

He's not wrong, Eduke32 sound system sucks ass

(There have been some significant improvement in the sound area, but it's still based on the old code)

[Radar]

NightFright, on 02 February 2020 - 11:37 AM, said:

We've been waiting for a port being able to handle all the important Build games for far too long, it's about time.

Fox, on 02 February 2020 - 12:19 PM, said:

He's not wrong, Eduke32 sound system sucks ass

You guys are aware he's just forking EDuke32 and its related projects, right?

[NightFright]

The real questions: Why is it done by HIM, with EDuke32 while he is a (G)ZDoom guy and only NOW?

[Radar]

Why doesn't he offer his contributions as an addition to EDuke32?

[Phredreeke]

Radar 100 Watts, on 02 February 2020 - 01:09 PM, said:

You guys are aware he's just forking EDuke32 and its related projects, right?

He's using EDuke32 and related projects for the game code, and he's also using Polymost for generating level geometry which is passed onto his own OpenGL backend. I don't see why he wouldn't do the same for music playback.

NightFright, on 02 February 2020 - 01:27 PM, said:

The real questions: Why is it done by HIM, with EDuke32 while he is a (G)ZDoom guy and only NOW?

My guess is EDuke32 removing the r_usetileshades CVAR was the final straw that pushed him to fork it

[NightFright]

Main issue I have with this: A guy from the Doom community is beating us to it. Doesn't feel right...

[Radar]

Beating "us" to "what"?

[Kyanos]

Multiplayer?

[Phredreeke]

I don't get why people think this would solve the multiplayer issue when GZDoom itself needs its own fork for it...

[Zaxx]

Radar 100 Watts, on 02 February 2020 - 01:36 PM, said:

Why doesn't he offer his contributions as an addition to EDuke32?

Guess because he's adding stuff from GZDoom and he's making alterations that wouldn't sit well with EDuke32's current state. For example I quoted that he ripped out all the old OpenGL stuff which is great but it also comes with issues regarding compatibility with older hardware, it may even have a performance cost. GZDoom doesn't really run on toasters anymore, it needs slightly newer hardware than it used to as newer stuff is implemented.

Anyway I'm just happy he's doing it because GZ is an incredibly experienced programmer who has a lot of issues with Build so chances are that through his different perspective he can find different or better solutions to certain problems Build ports can have. We'll see what comes out of it, hopefully he won't fail like Kaiser failed with Blood lately.

[Kyanos]

Phredreeke, on 02 February 2020 - 02:35 PM, said:

I don't get why people think this would solve the multiplayer issue when GZDoom itself needs its own fork for it...

I'm completely ignorant about doom ports, so I asked.
Has GZ mentioned multiplayer build at all?

nevermind i found a quote

Quote

I'll be honest here: Unless someone else is helping out here, I won't be able to maintain the multiplayer/networking side. That'd completely bog me down and leave no room for the things I'm really interested in, like working on the renderer.

[Hank]

To OP - best wishes to him. We'll simply have to wait and see what he can bring to the table.
He has not beaten anyone to anything. EDuke32 is fucking complicated to work with.

[Jimmy]

Yeah this is much ado about nothing.

[Morpheus Kitami]

I concur that as of yet, this is a nothingburger. The impression I've gotten from sometimes looking at the development board whenever getting a mod for ZDoom, is that Graf has short bursts of brilliance in-between disappearing for months or arguing with people over slights real and imagined.

Of course, I don't really notice these kinds of things to begin with, so I'm probably not the target audience for a different port. Unless he adds something like Decorate to Build. Would that even be necessary? I'm not sure how difficult it is for someone to add new weapons and enemies into Build...

[Radar]

Zaxx, on 02 February 2020 - 02:43 PM, said:

Guess because he's adding stuff from GZDoom and he's making alterations that wouldn't sit well with EDuke32's current state. For example I quoted that he ripped out all the old OpenGL stuff which is great but it also comes with issues regarding compatibility with older hardware, it may even have a performance cost. GZDoom doesn't really run on toasters anymore, it needs slightly newer hardware than it used to as newer stuff is implemented.

Anyway I'm just happy he's doing it because GZ is an incredibly experienced programmer who has a lot of issues with Build so chances are that through his different perspective he can find different or better solutions to certain problems Build ports can have. We'll see what comes out of it, hopefully he won't fail like Kaiser failed with Blood lately.

I've always supported keeping EDuke32 as vanilla as possible. But I understand the above changes in Graf's fork if the goal is to be able to support Doom style modding practices, but Rachael himself has said:

Quote

Right now the focus is more on usability (and actually being able to PLAY the games without frustration) than mods.

Well, none of the above features are of any value when it comes to playing the vanilla game. So imo the scope of this fork is not clear.

Phredreeke, on 02 February 2020 - 02:35 PM, said:

I don't get why people think this would solve the multiplayer issue when GZDoom itself needs its own fork for it...

And considering 75 from the Doom community is already helping the EDuke32 team develop the new client/server netcode, I'm not sure if this fork would be effective in attracting a new audience of developers.

[Tea Monster]

New eyes, new mind applied to problems. It's not going to be a straight 'rip' of EDuke or Polymost from what he's said.

He may just fix some things that the EDuke32 devs haven't got round to. The more the merrier.

Even if all he does is replace the rather busted Polymer with GZDooms PBR renderer, it will be well worth it.

This is some work that a guy called Arl did using just sprites with normal/roughness maps.

[Zaxx]

Radar 100 Watts, on 02 February 2020 - 07:03 PM, said:

So imo the scope of this fork is not clear.

I think that if you read through the full thread then the scope becomes clear but it's early days, this won't mature into a good port in a week and if you look at the "teaser" it's clear there are still lots of problems to solve.

[Fox]

NightFright, on 02 February 2020 - 01:42 PM, said:

Main issue I have with this: A guy from the Doom community is beating us to it. Doesn't feel right...

That would be really underestimating the amount of work necessary.

[NightFright]

Guess it's time to wait for the result. In the end it doesn't really matter who's doing it if it's done right.

[Zaxx]

NightFright, on 03 February 2020 - 03:01 AM, said:

Guess it's time to wait for the result. In the end it doesn't really matter who's doing it if it's done right.

What's "it" though? I mean this is not really a port that we need (though if Doom Builder would be compatible with Build as a result...): EDuke32 doesn't have serious issues (bugfixes, optimization and "future proofing" are the stuff that should be in focus now, other than that the port is great, it's done), BuildGDX and NBlood is getting more and more mature, etc. These days this is one of the biggest problems I have with EDuke32 and stuff like this is hardly game breaking:

So cool, a new port is being worked on with the potential of some new features and improvements but none of those will be game changers. The way I see it this "GZBuild" could be a good alternative for people who want something other than the "Crispy Duke" approach of EDuke32: less vanilla, more of a rendering powerhouse.

[oasiz]

Tea Monster, on 02 February 2020 - 11:23 PM, said:

New eyes, new mind applied to problems. It's not going to be a straight 'rip' of EDuke or Polymost from what he's said.

He may just fix some things that the EDuke32 devs haven't got round to. The more the merrier.

Even if all he does is replace the rather busted Polymer with GZDooms PBR renderer, it will be well worth it.

This is some work that a guy called Arl did using just sprites with normal/roughness maps.

I hope that any new renderer will still stay compatible with old maps.
Polymer might have it's share of problems but it at least works.

Many rendering methods fall apart with the nature of Build's geometry and comparing Doom to Duke is a bit unfair. There is a reason why Quake/Doom can look so nice as they actually follow 3D standards closer and the geometry is fully static.
Build itself is OK but the things it allows you to do is like a bag of edge cases. If you try to obey rendering conventions or physics, you might end up just breaking things as so many things rely on quirks.

A new renderer must work with the game and not against it, otherwise why even use build when ultimately something like doom WILL serve better.
Creating a compatible renderer is not an easy task.

[Micky C]

I'm not sure how much you've read up on this, but it sounds like he's using polymost to generate the geometry, and then separate code to do the actual drawing. Whether it works perfectly or not remains to be seen, but he's not making a renderer from scratch at least.

[Zaxx]

I think he mentioned that he wants to make a new renderer but that will happen later. Guess he wants to salvage Polymer or at least some of its features.