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