Raze officially revealed!

News about ZDoom, its child ports, or any closely related projects.
[ZDoom Home] [Documentation (Wiki)] [Official News] [Downloads] [Discord]
[🔎 Google This Site]

Moderator: GZDoom Developers

Post Reply
User avatar
Redneckerz
Spotlight Team
Posts: 1050
Joined: Mon Nov 25, 2019 8:54 am
Graphics Processor: Intel (Modern GZDoom)

Re: A new build engine is being developed!

Post by Redneckerz »

Graf Zahl wrote: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.[/quote[
Glossing over your list, it seems that you have replaced a lot more than i initially assumed. I can see certain parts being very useful to the Duke community, and others subject to critical verification (such as replacing the menu code). I can see that being a point of contention. As it stands, its definitely a product of its own and certainly no easy merge of two major codebases, if that ever was the case.
Graf Zahl wrote: [*] 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. ;)
This is however one of the more interesting bulletpoints and also one of the points i feel has a universal reach. An optimized Polymer-like replacement is something that could be very worthwhile, if only so that the Polymer option actually becomes a viable option instead of a Only try this at home feature due to its performance penalty.

The rest is personally a QoL thing for developers, but as i said, acceptance of that may vary. Fortunately due to the BSD license, folks will be free to take a look around and see what sticks and what does not - So overall, this is a good development Graf. :wink:
Gez
 
 
Posts: 17833
Joined: Fri Jul 06, 2007 3:22 pm

Re: A new build engine is being developed!

Post by Gez »

There's also kind of a domino effect, though, in that some changes required some other changes which required some other changes and so on, which is why the whole project took longer than originally planned. If you're interested in the performance improvement from change A, but for it to work you also need change B, which was only possible because of change C, and you don't want change C, then you're kind of out of luck.
User avatar
Phredreeke
Posts: 293
Joined: Tue Apr 10, 2018 8:14 am

Re: A new build engine is being developed!

Post by Phredreeke »

Graf Zahl wrote:
  • 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. ;)
That's what I was hoping for.
Graf Zahl wrote: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.
Yes, that makes sense, I believe that is how BuildGDX does it. Would it be possible to implement some kind of in-engine palswapping for high res tiles? Either through something like Polymer's highpals or simply (re-)indexing the input.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: A new build engine is being developed!

Post by Graf Zahl »

Using highpals isn't really complicated because the renderer already requires a shader. A highpal lookup would mean one more line of code in the shader plus the support code to load them. I may even add the feature to GZDoom.
User avatar
Tea Monster
Posts: 30
Joined: Tue Nov 13, 2018 6:08 am
Contact:

Re: A new build engine is being developed!

Post by Tea Monster »

If you have separated the rendering core from the rest of the code, would it be possible to incorporate GZDoom's PBR renderer for your Build port? Polymer has so many issues. Is it worth fixing?
Also, are you going to be making a separate editor? Something along the lines of Doombuilder?
User avatar
Rachael
Posts: 13530
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

Re: A new build engine is being developed!

Post by Rachael »

Tea Monster wrote:Also, are you going to be making a separate editor? Something along the lines of Doombuilder?
Our team does not do the editor.

UDB could be extended to add Build support for all supported games, but it'll take probably at least a couple days for them to get everything working just right, and it's up to the maintainers if they even want to do that. Luckily the Build format is extremely simple and well documented, but the simplicity also imposes a ton of limitations that make the map format harder to work with for a regular user.

There is also one other caveat: Build allows intersecting geometry, so UDB would have to turn off its auto-split-on-intersection feature by default when working with the format, if this were ever to come to fruition. 3D mode would also require some changes to work well with it since the player moves in 4 dimensions (XYZ+Sector) instead of 3 in Doom.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: A new build engine is being developed!

Post by Graf Zahl »

Tea Monster wrote:If you have separated the rendering core from the rest of the code, would it be possible to incorporate GZDoom's PBR renderer for your Build port? Polymer has so many issues. Is it worth fixing?
The end goal should be that the high level renderer will output data that is fully compatible with the backend parts of GZDoom. Once that works all the rendering effects should be available. With Polymost this isn't so easy because the output has its coordinates mangled so that these algorithms no longer work.
Tea Monster wrote:Also, are you going to be making a separate editor? Something along the lines of Doombuilder?
No. And I think this is the biggest problem of the Build games that editor and engine are built on the same code. In the end it probably stalled development of both.
Rachael wrote: UDB could be extended to add Build support for all supported games, but it'll take probably at least a couple days for them to get everything working just right, and it's up to the maintainers if they even want to do that. Luckily the Build format is extremely simple and well documented, but the simplicity also imposes a ton of limitations that make the map format harder to work with for a regular user.

There is also one other caveat: Build allows intersecting geometry, so UDB would have to turn off its auto-split-on-intersection feature by default when working with the format, if this were ever to come to fruition.
I think as a first step even an editor that doesn't allow overlapping sectors but on the other hand offers some modern UI would be a huge boost. Of course one other thing to consider is that Build does not all that open sector hackery that is so popular among vanilla Doom mappers. I'm also not sure how 3D in the editor would cope with overlapping sectors - in particular things like Lunatic Fringe or EDuke's true ROR.
User avatar
wolfmanfp
Posts: 80
Joined: Mon May 08, 2017 11:44 am
Graphics Processor: nVidia (Modern GZDoom)
Location: Hungary
Contact:

Re: A new build engine is being developed!

Post by wolfmanfp »

Graf Zahl wrote: I think as a first step even an editor that doesn't allow overlapping sectors but on the other hand offers some modern UI would be a huge boost. Of course one other thing to consider is that Build does not all that open sector hackery that is so popular among vanilla Doom mappers. I'm also not sure how 3D in the editor would cope with overlapping sectors - in particular things like Lunatic Fringe or EDuke's true ROR.
Overlapping sectors are working in Duke Builder, see here at 1:50:
User avatar
Rachael
Posts: 13530
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

Re: A new build engine is being developed!

Post by Rachael »

wolfmanfp wrote: Overlapping sectors are working in Duke Builder, see here at 1:50:
That's all well good and all, but remember that in Build two sectors can occupy the exact same XYZ space (which is why I list the sector number as an additional dimension). They do not need to be at different Z heights for this to work.
User avatar
Tea Monster
Posts: 30
Joined: Tue Nov 13, 2018 6:08 am
Contact:

Re: A new build engine is being developed!

Post by Tea Monster »

Would it be possible to use Polymost's coordinate system to create a 'real' 3D engine for Build? To have proper XYZ coords. There are a number of utilities that will take a Build map and turn it into an proper 'real' obj file that you can open in 3DMax or Blender with all the level geometry present and correct in every dimension. So I know it's technically possible. I don't know if that would be able to be used to facilitate a TROR system that would wouldn't suffer from some of the hacky crap that has existed up to now.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: A new build engine is being developed!

Post by Graf Zahl »

The map isn't the problem, it's what Polxmost does with the map. It performs lots of transformations in software and then hands these processed coordinates to the backend. But all the lighting effects in GZDoom work by giving the backend a list of light sources in world coordinates and each rendered element a list of lights. So the entire thing only works when both use the same coordinate space. With Polymost as-is this isn't the case. Of course there are ways to re-transform the coordinates but unfortunately the entire code is very obtuse and hard to follow. At the moment I simply do not know how to do this. Of course if someone cracks this nut the light effects could be done in Polymost as a stopgap measure until a new renderer is ready.
User avatar
Rachael
Posts: 13530
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

Re: A new build engine is being developed!

Post by Rachael »

This is a whole lot more complicated than Graf describes - otherwise it would likely be possible to do the translations directly with the light code, itself, then, as a stopgap until the new renderer is ready.

That being said you can't just feed XYZ info to the renderer since, due to TROR, multiple sectors can be in view that overlap. The light shader would have to know what sector it is currently rendering, and what sector the light is emitted from, and whether the two sectors are visible from one another. This adds a whole layer of complexity that, if it's not handled right, will cause lighting effects to appear in the wrong sector.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: A new build engine is being developed!

Post by Graf Zahl »

I already solved that part in GZDoom - it's no more complicated here. Lights only light surfaces they are attached to, no matter where in the map they are.
User avatar
StrikerMan780
Posts: 485
Joined: Tue Nov 29, 2005 2:15 pm
Graphics Processor: nVidia with Vulkan support
Contact:

Re: A new build engine is being developed!

Post by StrikerMan780 »

Graf Zahl wrote:
StrikerMan780 wrote: 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.
The purpose of using shaders wasn't for saving memory, but to prevent stutters and hitches that occurred when generating the textures per palette.
wolfmanfp wrote: Overlapping sectors are working in Duke Builder, see here at 1:50:
Overlapping is one thing. Intersecting is another.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: A new build engine is being developed!

Post by Graf Zahl »

StrikerMan780 wrote: The purpose of using shaders wasn't for saving memory, but to prevent stutters and hitches that occurred when generating the textures per palette.

OK, so it was just another workaround for the texture creation problem. How good then that I found and fixed the real cause.
Post Reply

Return to “ZDoom (and related) News”