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

If it's not ZDoom, it goes here.
Talon1024
 
 
Posts: 374
Joined: Mon Jun 27, 2016 7:26 pm
Preferred Pronouns: He/Him
Graphics Processor: nVidia with Vulkan support
Contact:

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

Post by Talon1024 »

Graf Zahl wrote:
Darkcrafter wrote:Is it theoretically possible to make hardware to render in 8 bit colors?
No, hardware cannot render in 8 bits, but what you can do is do the entire shader processing paletted. This is essentially what EDuke is doing - it only applies the real color to the fully postprocessed palette index. The downside of such an approach is, of course that you can pretty much forget any kind of advanced render effect which needs to operate on real colors.

This wouldn't even be too hard to add to GZDoom, but it'd clash with some shader based effects.
Jazz Mickle wrote a post on Medium about how they wrote a shader to make the 3D rendered scene of a Doom level look like it was rendered with Doom's software renderer.

For stuff that isn't using the PLAYPAL, I would apply the existing palettizing shader first, and then apply Jazz Mickle's shader effects.
User avatar
Phredreeke
Posts: 295
Joined: Tue Apr 10, 2018 8:14 am

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

Post by Phredreeke »

This is from my understanding how EDuke32 and related ports also do it :P
User avatar
Hendricks266
Posts: 10
Joined: Tue Jun 24, 2014 4:26 pm
Location: United States
Contact:

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

Post by Hendricks266 »

Teddipetzi wrote:And what do I see here? The exact opposite - going back to the roots and preserving that old 90's crappy palette look.
Graf Zahl wrote:What can I say? Welcome to the wonderful world of retro game development, where the greatest achievement is not to enhance the games and bring modern features to them but to meticulously preserve all the warts and bumps the games originally had to the greatest extent imaginable. Similar things often happen over at Doomworld, just witness the 4(!) featured retro ports.
Graf Zahl wrote:There's also this horrible stench of retro absolutism to be smelled here that's also quite widespread over at Doomworld, i.e declaring the technical limitations of the 90's an artistic merit. Aren't we here to improve matters and not trying at all costs to keep them the same?
I still remember General Arcade's reaction when I patched EDuke32's tileshades implementation into Megaton and Redux: "Wow, this is way more atmospheric."

No one is declaring the technical limitations themselves an artistic merit. In fact, I have repeatedly argued against shaders that dynamically pixelate 3D models at render time, as seen in Prodeus.

What's important is that the colors chosen in a lookup table define the aesthetic of a game, and ignoring them in the name of "technological progress" only breaks what the original authors created. Case in point:
Graf Zahl wrote:Correct. Ion Fury has such an issue - the red color range has a totally weird off-kilter fade ramp that defies any mathematical approach. All the rest works fine but the red is totally off. To get it right I think it'll be necessary to extend the palette to 9 bits and recalculate everything so that at the bright end it doesn't degenerate into that white-ish orange. Heretic also got a yellow range that tops out as white, it's really something I eventually want to find a solution for. Of course I am looking for solutions that do not involve palettization of the output image.

One interesting effect I generally noticed from the color crush that happens with paletted color maps is that the resulting image is often a lot darker than doing the linear calculation directly, I've seen that in nearly every game I checked.
I believe the overbright section of these ramps are used to represent the physical appearance of fire. Maybe Cage could describe more specifically what he intended when creating Fury's palette and shade table.
Graf Zahl wrote:But I have to admit that the deliberate preservation of the paletted visuals was why I refrained from buying Blood Fresh Supply. I do not pay money for that kind of stuff.
That thing is an approximate program code remake of the original game, and the fact that they got the appearance right was what kept you from buying it?
Graf Zahl wrote:Just look at the Doom port landscape for how things really are. No, it's not the pixel perfect retro ports that are the most popular - it's the hardware rendered ones that do away with the limitations. Of course most of those users will never visit the forum so you never hear their voice.
GZDoom rode on ZDoom's back for years, and even today we're not posting on "gzdoom.org", are we? Which one of these had the hardware-accelerated renderer?

Even if your claim were correct, all it would show is that noobs love shiny things and buzzwords. Popularity is a self-fulfilling cycle: people love to like what they see other people liking. I would bet most of the people you're talking about are also the crowd who plays Duke for the first time with the HRP and Duke Plus, or Doom with the ruthless mod that must not be named.
Graf Zahl wrote:Let's just phrase it this way: A consumer has every right to be absolute about their choice. Which pushes the ball back into the developers' field which need to provide the needed options. And that clearly also implies not removing options and declaring that an improvement. As we can see here, some people do not take that well. If some option needs to be removed there needs to be a good, justifiable reason. And that's something I cannot see here.
It would not be hard to re-add a cvar to disable the accurate shading pipeline for people who just can't get over it. We already have a content-side flag to do this for Duke 64. I would re-add the cvar struct and the variable it uses, grep the source for GLOBAL_NO_GL_TILESHADES, and plug it in there. Done.

It won't be re-added as a menu option though. The only reason early IM builds had a Palette Emulation toggle was because our previous implementation had a performance impact. This is now fixed. There is no reason to use up menu space with a "break the game's colors" option.
Kinsie wrote:The extensive and inventive collection of profanity and "Hey Kinsie, wanna hear how the engine's busted this week?" stories I've heard throughout the year from a CON scripter on a large mod project suggests that the collision overhaul has been a perhaps less-than-smooth process.
Most of the issues you are speaking of have since been fixed. Despite your insinuation, the AMC TC team has been gracious with identifying regressions and contributing patches to fix them.
Phredreeke wrote:This is from my understanding how EDuke32 and related ports also do it :P
Yes, that's correct.
Graf Zahl wrote:And please - please(!) show me the code that got cleaned up. Because I cannot find any traces of this, despite looking.
Maybe try opening your eyes: find a copy of duke3dsource.zip and start comparing.
Teddipetzi wrote:Also, from what I have been reading between the lines of Graf Zahl's postings about this matter over the last two months I suspect he's got something up his sleeve that will make EDuke32 look very, very old.
To quote Duke, how many alien races have to get their asses kicked?
User avatar
Fox666
Posts: 139
Joined: Thu Feb 24, 2011 12:45 am

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

Post by Fox666 »

Graf Zahl wrote:No, actually, that's not what you'll see. You are forgetting one important piece in the chain and that's the monitor.
There's also this horrible stench of retro absolutism to be smelled here that's also quite widespread over at Doomworld, i.e declaring the technical limitations of the 90's an artistic merit. Aren't we here to improve matters and not trying at all costs to keep them the same?

Just look at the Doom port landscape for how things really are. No, it's not the pixel perfect retro ports that are the most popular - it's the hardware rendered ones that do away with the limitations. Of course most of those users will never visit the forum so you never hear their voice.
Honestly all I can think of is this

[imgur]https://i.imgur.com/qGjiupr[/imgur]
User avatar
StrikerMan780
Posts: 485
Joined: Tue Nov 29, 2005 2:15 pm
Graphics Processor: nVidia with Vulkan support
Contact:

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

Post by StrikerMan780 »

Graf Zahl wrote: Ok, well, if you think so, but I cannot agree. The code is so performant that it renders the opening scene in Ion Fury with about the same performance on my system as the infamous bridge scene in Frozen Time gets done in GZDoom (12 ms processing time each) - that scene has 13000 linedefs visible all at once. And please - please(!) show me the code that got cleaned up. Because I cannot find any traces of this, despite looking.
Try doing the opening scene of Ion Fury on the original Duke3D source and marvel at the sub-1fps you'd get.
User avatar
Rachael
Posts: 13571
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

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

Post by Rachael »

I don't really like how this topic is devolving. I think the points that need to be made have been made, and at this point it's going to just start into arguing and a flame war. So because of this, I'm going to stick the deadbolt on it. Sorry for the inconvenience.
Locked

Return to “Off-Topic”