Raze officially revealed!

[SouthernLion]

I'm excited about this. Duke Nukem is one of my all time favorite fictional heroes since I was a kid. From battling Proton to Duke Nukem Forever. (Which I actually liked. Well.. liked more than the average person.) lol Reading this thread, I've learned more about the Build Engine Source Ports than I thought I would.

[Kinsie]

I'm interested to see how this plays out within the community, I can see this becoming the de-facto standard but I'm worried some of the original devs might adopt a "Bernie or Bust" attitude and not be supportive. Hoping for the best though, I think some of your comments have hit nerves but since you're producing solutions and its no longer talk, I'm hoping for a much warmer reception.

The impression that I'm getting (through second hand sources so I'm open to being corrected) is that the eDuke32 folks probably won't merge back in parts of Graf's port for various complicated reasons revolving around the licensing and Ion Fury's commercial usage of the engine. Which is kind of a pity because deeper co-operation would have been nice, but given that the Doom community cheerfully survives with multiple only-kinda-compatible engines, it's not the end of the world.

[Blzut3]

for various complicated reasons revolving around the licensing and Ion Fury's commercial usage of the engine

Which is absurd since I'm fairly sure Graf would license any new code as BSD like is done with (most of) GZDoom. That's if it isn't already since it's the easiest way to resolve conflicts between one project being GPLv3 and the other GPLv2. (And that's ignoring the build license issues.) One thing I've found hilarious is that despite being very liberally licensed this isn't the first time someone has hesitated to take code from (G)ZDoom.

[Gez]

One thing I've found hilarious is that despite being very liberally licensed this isn't the first time someone has hesitated to take code from (G)ZDoom.

From the other Doom ports, it was "it's not GPL, so we can't use it" and when GZDoom went GPL the situation had already largely fossilized, with PrBoom(+) having largely stopped development, Eternity wanting to do things its own way, and other ports being mostly Chocolate Doom forks. There are some ports that borrowed from ZDoom without being derived from it, however, like Vavoom, but they were kinda niche.

If ZDoom had been GPLed, in the early 2000s, thing would probably be very different today. Of course, it wasn't technically possible because Heretic/Hexen code, FMOD, yadda yadda.

[Graf Zahl]

Agreed here, unfortunately Nuke.YKT's efforts with porting Redneck Rampage sort of undermined that goal because he gutted the engine to enable demo compatiblity. So now we have two ports that are identical for large parts but have other elements that are bound to cause problems with merging. I'm also not quite certain if there won't be clashes with the scripting because both code bases uses certain values for different things.

I suspect it was that he needed something closer to vanilla Duke to graft the reverse engineered differences from RR onto, and demo compatibility just being a happy accident.

That may have been part of the reason but whatever it was it's ultimately still regrettable. I think with a lot of effort both code bases can be merged but it'd be a gargantuan amount of work to make sure it works correctly. I

for various complicated reasons revolving around the licensing and Ion Fury's commercial usage of the engine

Which is absurd since I'm fairly sure Graf would license any new code as BSD like is done with (most of) GZDoom. That's if it isn't already since it's the easiest way to resolve conflicts between one project being GPLv3 and the other GPLv2. (And that's ignoring the build license issues.) One thing I've found hilarious is that despite being very liberally licensed this isn't the first time someone has hesitated to take code from (G)ZDoom.

Repeating what I said in our private discussion:

The licensing concerns are genuine, actually. They cannot accept external GPL code because it does not comply with their linking exception to the Build code and they cannot accept Build licensed code because it prohibits commercial use - unless an exception is given.
As long as they depend on Build licensed code they are very limited in what they can accept into a commercial engine - virtually the only thing are permissive licenses like MIT or BSD.
They currently have no idea what license I am using. Yes, it's all BSD 3 clause, but I never said that publicly. This one is a genuine concern for commercial code and well founded. At my workplace we also have to double and triple check not to include licensing poison pills into our code base that could undermine its commercial viability. And those poison pills are not just GPL licensed pieces. Actually far worse are some commercial libraries that come with nasty strings attached. We only buy third party code if it means we get a perpetual no royalties license.

From the other Doom ports, it was "it's not GPL, so we can't use it" and when GZDoom went GPL the situation had already largely fossilized, with PrBoom(+) having largely stopped development, Eternity wanting to do things its own way, and other ports being mostly Chocolate Doom forks. There are some ports that borrowed from ZDoom without being derived from it, however, like Vavoom, but they were kinda niche.

Let's be clear here: Entryway took code from GZDoom for the GL renderer in PrBoom+. The entire issue here was frequently blown out of proportion solely by Team Eternity who made things look more complicated than they really are. The only reason with the other existing ports is that they are too basic to have any use for ZDoom's code - the only one ever interested in some form of feature parity was Vavoom. EDGE doesn't count because its roots are simply too different. If there was opportunities to share I'm sure they'd be taken. Coraline is the one of the other port devs I've been having the most private discussions with about such things.

So we're back to one single person who ever acted like that - but even Eternity borrowed heavily from ZDoom in the past for its 3D capable movement code.

[Teddipetzi]

All these discussions about letting EDuke borrow from this port leave out one critical point:
From reading Graf's posts I got the impression that this is more like grafting the game code of all those Build games onto the GZDoom engine. In other words: There's probably little that could be backported without swapping out entire subsystems of the engine.
So it might be interesting if we knew in more detail which parts are still there and which have been replaced. Any information about this, please?

[mjr4077au]

All these discussions about letting EDuke borrow from this port leave out one critical point:
From reading Graf's posts I got the impression that this is more like grafting the game code of all those Build games onto the GZDoom engine. In other words: There's probably little that could be backported without swapping out entire subsystems of the engine.
So it might be interesting if we knew in more detail which parts are still there and which have been replaced. Any information about this, please?

My impression was that it's EDuke32 with GZDoom's UI, video and audio subsystems. I beleive it's still more EDuke32 than GZDoom. The renderer is still Polymost for instance, it just sends it to the video backend rather than the intertwined OpenGL code it had before.

[Redneckerz]

The difference is Graf has been programming professionally since 1994 (when I was only 4 years old ), whereas I think the EDuke32 guys are more hobbyists and tinkerers. That explains the bolt-ons without the true fixes that I think are widely accepted as necessary (refactoring of code, etc).

AFAIK Terminx has done programming work prior. There are ofcourse differences in code quality, but safe to say Terminx and co did do quite a lot of work with the existing Build codebases, but considering where they came from, a good improvement.

The impression that I'm getting (through second hand sources so I'm open to being corrected) is that the eDuke32 folks probably won't merge back in parts of Graf's port for various complicated reasons revolving around the licensing and Ion Fury's commercial usage of the engine.

Similar, but i imagine how Graf phrases things also sets off a fuze, even when its about Build code in general and not about personal antics. However, the move to BSD is a good decision and i think that definitely helps presenting this. It also shows Graf's intention with this work - More community in spirit,i feel.

All these discussions about letting EDuke borrow from this port leave out one critical point:
From reading Graf's posts I got the impression that this is more like grafting the game code of all those Build games onto the GZDoom engine. In other words: There's probably little that could be backported without swapping out entire subsystems of the engine.
So it might be interesting if we knew in more detail which parts are still there and which have been replaced. Any information about this, please?

I am fairly certain it was mentioned that details would come up shortly.

Its not grafting Build code into GZDoom, rather - Its EDuke32 by default that does all the rendering. GZDoom is used for UI, input and post-processing, along with some other renderer things. Then there are several other codebases to implement specific game support. All in all, its an engine that works around game modules, similar to BuildGDX (as Graf said).

The full feature list and extension of what Graf's sayings mean should become clear when a readme and the alpha are released, which is imminent.

[Gez]

From reading Graf's posts I got the impression that this is more like grafting the game code of all those Build games onto the GZDoom engine.

It's the other way around really, plugging in some parts of GZDoom's backend code. The engines are still from the original ports that are getting integrated.

It's more like something such as ScummVM; though obviously on a much smaller scale. There's a shared backend that deals with input/output issues for the system interface, but it's still the games that process these inputs and produce these outputs.

[Graf Zahl]

The real answer lies in the middle, of course. It is true that there was very little being added to the existing code - most was replacing entire subsystems indeed.

Polymost is still there, at least the part that builds the geometry - but all the low level stuff has been completely removed, all the texture management, shader setup and lighting is done in the backend.
A quick overview over the biggest alterations:

• the entire file system code inherited from Build was replaced with a reworked and extended version of GZDoom's WAD manager to work more like a real virtual file system. For Blood I merged the 3 distinct file systems (directory, Blood.rff, Sounds.rff) together into one. It would require quite elaborate fuckery to use Blood's system in a way that could break this changed setup, but will make it a lot easier to design mods for. I think the advantages far outweigh the potential but mostly theoretical problems.
• the Build memory cache was entirely removed with no replacement. For technical reasons most that was put into it needs to be permanently loaded anyway so no real loss.
• Build OSD and configuration maintenance was replaced with ZDoom's console and config code.
• Polymer had to be entirely disabled for the time being. The main problem is that it needs too much support code outside the renderer and couldn't be as easily uncoupled from OpenGL as Polymost. I fully intend to bring its core features - but not the renderer implementation itself - back, once the entire engine is in a more stable state than right now. Actually, programming a new renderer that is better equipped to work with current graphics hardware would be where the real fun lies.
• Replacement of all menu code with ZDoom's menu engine (the last version before it got scriptified)
• Using GZDoom's backend for system maintenance and input. On Windows and Mac SDL is no longer used.
• Uses CMake as its sole building system.

[Graf Zahl]

Its not grafting Build code into GZDoom, rather - Its EDuke32 by default that does all the rendering. GZDoom is used for UI, input and post-processing, along with some other renderer things. Then there are several other codebases to implement specific game support. All in all, its an engine that works around game modules, similar to BuildGDX (as Graf said).

A little correction here: EDuke32 itself does no rendering itself, and neither do NBlood, RedNukem etc. The rendering is entirely done by Ken Silverman's Polymost code.

[StrikerMan780]

That's great news. EDuke controller support and set-up was terrible!

That's been fixed for a while now, since Ion Fury's release.
https://dukeworld.duke4.net/eduke32/syn ... 0201-8576/
This build should be alright. You may want to delete your configs if they're very old, though.

But ultimately it will be optional, not forced.

If we ever want advanced lighting effects it must be optional. Since this code is doing the entire lighting by using 8 bit lookup tables there is no way it can ever work with dynamic lighting and even less with more advanced stuff.

Well, not entirely. In EDuke32, the LUT is only applied to 8-bit assets. True color and 8-bit textures and sprites can be used in the same scene, and only the 8-bit ones will be affected by palette emulation. Palette emulation in no way hinders the ability to display 32-bit assets. In Polymer, palette emulation and dynamic lights can be mixed too, doesn't affect the color of the lights. Polymost doesn't have any dynamic lighting, but if one were able to get it working, I think it'd be possible to mix the two.

[Graf Zahl]

Careful! I believe you are mixing two things up. There's two levels of palette emulation. If you just use the texture with the LUT as your texel input it can surely be used for lighting and that's how Polymer works from what I have seen

But that's not the case if you use Nuke.YKT's code to use the shade maps for applying lighting. In that case the lighting is no longer generated by multiplying the texel color with a light value, but by actually replacing the color through another LUT. And once you are there you cannot use real lighting anymore because you already lost some important bits of color info and the result may just look off. AFAIK Polymer doesn't implement this mode.

[StrikerMan780]

Careful! I believe you are mixing two things up. There's two levels of palette emulation. If you just use the texture with the LUT as your texel input it can surely be used for lighting and that's how Polymer works from what I have seen

But that's not the case if you use Nuke.YKT's code to use the shade maps for applying lighting. In that case the lighting is no longer generated by multiplying the texel color with a light value, but by actually replacing the color through another LUT. And once you are there you cannot use real lighting anymore because you already lost some important bits of color info and the result may just look off. AFAIK Polymer doesn't implement this mode.

I might actually be thinking of something that was done prior to Nuke.YKT's changes (which looks nice, to be fair, especially with interpolation on). Some time before that, pogokeen got rid of the old way of palette emulation (copies of textures for every shade and palette), and moved to shaders instead, but light information was unchanged. You'd probably need to disable Nuke.YKT's shade map code for it to work with dynamic lighting. Just wasn't sure if pogo's change would be a hindrance or not (probably wouldn't).

[Graf Zahl]

I might actually be thinking of something that was done prior to Nuke.YKT's changes (which looks nice, to be fair, especially with interpolation on). Some time before that, pogokeen got rid of the old way of palette emulation (copies of textures for every shade and palette), and moved to shaders, but light information was unchanged.

Yes, that was also there - of course the drawback was that it also lost all texture filtering options. This was what I restored - but I left it at one texture per palette, doing the shades with hardware lighting. On today's graphics hardware this kind of memory saving isn't really needed, especially for lo-res assets.