OpenGL renderer overhaul progress

Status
Not open for further replies.

Eidolon

Developer
Sonic Team Junior
Kart Krew™️
Hey everyone, I'm back with more insane SRB2 hacking nonsense.

So, here's a progress update on what I'm working on. I'm overhauling OpenGL to have visual parity with the software renderer in the hopes that it will replace SW and become default for most users.

Here's a proof of concept video for using GLSL shaders to handle palettized rendering of the entire screen, including colormapped software style lighting: https://www.youtube.com/watch?v=wXrot6Gays0

GmCa8cj.png


I am also working on significant optimizations to the vertex pipeline. Right now it is very inefficient and in very dense levels the CPU overhead becomes significant enough to put a dent in my monster of a desktop's framerate (particularly noticable in my uncapped branch). That's pretty unacceptable, so I'm figuring out ways to reduce the draw calls (in my projection, from N calls where N is the number of triangles on screen, to N where N is the number of textures in use in the frame). This will pave the way for an efficient Android port.

I am documenting everything I'm working on here on the code dev wiki: http://git.magicalgirl.moe/STJr/SRB2/wikis/opengl-cleanup. For those knowledgable about graphics programming and SRB2's codebase, I would like help! Please come on IRC and talk with me.
 
Was on 'fun as you were working on this. I got to say, this is one of the most amazing things I've seen; I might actually start using OGL now once this is completely done!

Best of luck in finishing it!
 
I checked the "code dev wiki" page as you call it, and... Let me get this right...

The (currently) two main portions of this is to optimize drawing a lot (really good thing) and introduce palette-based rendering (one of the main things people play OpenGL to avoid) to OpenGL (probably bad thing, depending on who you ask)?
I definitely hope there will be a console variable to turn off the latter, if that's the case...

If the latter is merely a proof-of-concept, and won't be included (or at least won't be forced), I really look forward to seeing this be completed. Especially when it comes to water surfaces. They're really wavy in software rendering, but OpenGL lacks the shaders to replicate that (as of now).
 
I've been wanting SRB2 to drop software in replacement of OGL for a while, best of luck on this.
I'm curious as to how far you're planning to go with this, for example:

Will you be able to accomplish something similar to SRB2CB's PNG edition and remove the palette restriction in replacement of full colour range?

Is it possible to keep the 'software parity' visuals as a filter or extra option so people can have a choice between using the 'software' look or the original OGL look?
 
I checked the "code dev wiki" page as you call it, and... Let me get this right...

The (currently) two main portions of this is to optimize drawing a lot (really good thing) and introduce palette-based rendering (one of the main things people play OpenGL to avoid) to OpenGL (probably bad thing, depending on who you ask)?
I definitely hope there will be a console variable to turn off the latter, if that's the case...

If the latter is merely a proof-of-concept, and won't be included (or at least won't be forced), I really look forward to seeing this be completed. Especially when it comes to water surfaces. They're really wavy in software rendering, but OpenGL lacks the shaders to replicate that (as of now).

Yes, it would be included, replace and be required by default unless your hardware doesn't support it (in which case it falls back to the old fixed func GL render code). The OpenGL renderer was never supposed to _not_ be palettized, in fact the original implementation used paletted textures. But the GL extension Legacy used is not supported on any video card in the last 15 years, so we've always had to convert the textures to true color before uploading them to the GPU. SRB2 has never supported truecolor internally and there is no reason to keep it unless we allow truecolor images in the game itself.

The rationale behind getting as close to software as possible is that there many effects in SRB2 that are only accomplished with palettes. The visual style is only possible with palettes, particularly with regard to translucency, in order to mimic the look of old SEGA Genesis Sonic.

I could add fixed-function mode forced as an option, but the fact of the matter is that OpenGL renders the game incorrectly right now. That's what I'm trying to remedy.
 
So, wait, if OpenGL is becoming palette-based, then what's going to happen to MD2s? Will their textures have to be paletted as well?
 
I've already said as much on Twitter, but I'll restate it here: deliberately handicapping OpenGL to 8-bit rendering for the purposes of "parity" is a fool's errand. Doing it for intellectual purposes, to prove it can be done, is an alright endeavor, but to then force it upon everyone, particularly people like myself who greatly prefer truecolor rendering, is a regression that I cannot and will not support.

And just to clarify before it's asked: no, I don't mean truecolor texture support (although support for, say, PNG textures in OpenGL - with Software using the nearest available palette entry, a la ZDoom - would be dandy). I'm talking about the lighting dropoff. Software uses COLORMAP to approximate this, but is still forced to use an entry in the defined 256 color palette, which can produce some ugly-looking color transitions (best illustrated in Doom, with noticeable loss of precision in dim areas in blues, such as in this room in E3M3 - vanilla, truecolor - or basically any instance of the "Pinky" Demons in dim environs, turning various shades of tan and gray instead of pink - vanilla, truecolor).

What I really think the disparity between Software and OpenGL is is that colormap handling is iffy (eg: Middle textures above FOFs with colormaps, like THZ slime, adopting the FOF's colormap despite not being inside the FOF) and the lighting dropoff is considerably weaker than it should be in comparison to Software (resulting in areas that are almost pitch-black in Software being still somewhat visible in OpenGL). Frankly, that's what should be tackled, not arbitrarily imposing the palette onto both renderers.

I mean, go ahead and implement it, it'd be an interesting curiosity - but don't make it mandatory, hell no.

[citation needed]
Just ask the Doom community. They've gone as far as experimenting with branches of Chocolate Doom that support truecolor (in fact, the images I cited above came from a DoomWorld thread for said branch).
 
Last edited:
Just ask the Doom community.
The truecolor stuff is nice and would be cool to have, but the point I was making is that you shouldn't just assume everyone has the same opinion as you. I personally hate the way how all the gradients look flat and lifeless in OpenGL, and I know a fair number of people that agree with me. So please don't call parity with Software a "fool's errand", because then you're calling me and a bunch other of people fools.
 
In which case having an option for it would be fine. But just that - an option for it. Forcing it upon everyone is rather assumptive in itself, that everyone's gonna prefer the (personally crappier) look because it's more "correct" (which in and of itself is debatable).
 
In theory having truecolor support is cool, but then that means you can't opt into using any cool palette tricks with the COLORMAP lump and the like... because those lumps of course aren't needed for truecolor support.

And then there's the issue of the flash palettes; all of the vanilla SRB2 flash palettes (white for teleport/misc effects, red for armageddon shield nuke) have to be simulated in the OpenGL renderer currently. That doesn't bode well for anyone hoping for different flash oalette colors when one of two renderers doesn't even support that properly.
 
In theory having truecolor support is cool, but then that means you can't opt into using any cool palette tricks with the COLORMAP lump and the like... because those lumps of course aren't needed for truecolor support.
The only "cool palette tricks" I've ever seen in the history of both Doom and SRB2 are forcing everything brighter (changing it so what should be pitch-black is only 25% black, 50% black, etc) and fog effects (fading to a color other than pure black). The former is a cheat, anyway, and the latter is basically already supported (GR_FOG).

And then there's the issue of the flash palettes; all of the vanilla SRB2 flash palettes (white for teleport/misc effects, red for armageddon shield nuke) have to be simulated in the OpenGL renderer currently. That doesn't bode well for anyone hoping for different flash oalette colors when one of two renderers doesn't even support that properly.
It's not that hard to tint a screen, I would imagine. That said, if we're missing a way to customize those tints, then that's an oversight that could stand to be fixed.
 
Last edited:
I'm kind of in the same boat as Shadow Hog here. Having a palletised mode is fine for people that prefer it this way, and to try and maintain parity, but I feel having proper colours for colourmaps is much more visually appealing than having instances where colours change to be completely wrong. The main example I can think of is the grass flat near the beginning (and probably in other places) of CEZ1, as well as any time strange coloured colourmaps are used.

I can see that there could be some small issues appearing like MonsterIestyn said with the flash palettes. But I feel if all that is needed is a screen tint, why use a completely new palette when it could just be the normal palette tinted?
 
Okay, but when is OpenGL gonna be fixed to not render translucent everythings completely wrong?

Also, I'm pretty sure palette effects (and light banding, etc) and truecolor rendering aren't mutually exclusive. Especially with the way I think the shader POC works; just using an auto-generated colormap texture that isn't bound to the palette (or user-supplied: GLCOLMAP/CGL####) should be the best of both worlds for people who prefer it that way?
 
Last edited:
Regardless of pallet shenanigans, as a programmer with limited graphics programming experience, I'd like to say thank you for taking the time to optimize the OpenGL mode. I'm just glad someone's doing it.
 
[citation needed]
Obvious example: The Doom community, as already stated by Shadow Hog.

Actual example: "When I recorded this before I used the... the standard .exe version of the game, which basically, in a lot of ways, makes the colours kind of a bit... weird. And playing in the OpenGL version makes everything nice and smooth and colourful. I think it's a change between, like 16 and 32 bit, I'm not sure though."

"Actual example" resumé:
"I used the standard version of the game, which makes the colours kind of a bit weird. And playing in the OpenGL version makes everything nice and colourful."


Again, I won't mind there being an OPTION for it, but I WILL mind it being FORCED.

Another thing I'll mind is everything looking way better with a horrible graphic card than a gaming graphic card...
Yes, it would be included, replace and be required by default unless your hardware doesn't support it -
Really, what's wrong with an option that can even default to being on?
 
Alright, I'll use an example from a Sonic game why software parity is my goal here.

SEGAGenesisClassics+2012-09-04+19-53-36-02.bmp


The water color is not a modulation of the color underneath with a tint color. It's a mapping from some color index to an alternative color to have the appearance of translucent water. The mapping function for tint blending, shown below:

gif.latex

where C is a True Color, to achieve the same visual aesthetic, is not quantifiable. We know what the end result should be, but the palettes used for mapping in the indexed function are not on a quantifiable, functional curve. There's a reason why fixed-func OpenGL doesn't look like software at all, and no amount of adjusting tints will ever approximate this well.

In a similar way, colormapping for lighting is not quantifiable.

SRB2 is and has always been about putting classic Sonic feel in 3D, and I think the software renderer's perceived faults with palettes actually accomplishes the visual aesthetic of class Sonic very well, particularly with 255-bright sectors. The reason for this, is Boom actually has essentially the same mapping function for translucency effects (which we inherent from in Doom Legacy for software).

Personally, I think tinting surfaces with true color blending actually washes out a lot of the color. It's appropriate for photorealism, but Sonic is not photorealistic. It's a very colorful game.

I do not think it is appropriate to get/keep photorealistic blends in the OpenGL renderer when the software renderer doesn't do it and maintains its visual color palette well without it.
 
Last edited:
I'm on the side of supporting software's limited palette, the graphics look a lot more uniform when all the sprites are fitting a unified color scheme; everything, especially the lighting, seems a lot more alive when they aren't monotonously gradiented. The game was just made for it, it fits the sprites better when you have an old school lighting and coloring environment to go with. Like... I REALLY like how software tints things and would never like that to ever go away.

It obviously doesn't apply for everyone, but the feel I get from OpenGL is that "it looks dead". That's not to say I'd shoot down the idea of truecolor for it as well, but if I had the coding expertise to do what you're doing, I'd save it for last and wouldn't worry about it much. Again, that's just me.


What I WILL say though is that this is a chance to HEIGHTEN the palette limit on SRB2's color line, we have a lot of shitty color picks that cannot be replaced because the game often looks strange without them. But I would like ADDITIONS, such as less horrible purples and yellows.
 
Last edited:
I am of the opinion that this works well for light levels / shadows and the parity is very much appreciated. I do hope that translucent and colormapped things will not be entirely and strictly restricted by old palette limitations, however; there is plenty of room for small, subtle and discrete improvements hardware rendering can provide which I believe won't entirely break the immersion of SRB2's software-rendered stylings if used properly and with discretion.

As Iceman's post above me states, it would actually be an immense boon if we could somehow add a few more color ramps to the palette -- although I am aware that doing so outright would break every file format and tool we use. :( Perhaps it could be done by cropping some of the existing ranges to only the brighter colors we actually use in the source images, and replacing the missing colors with "implied" darker tones only used by shading? ... But I digress, that is a discussion for another day.
 
Last edited:
Alright, I'll use an example from a Sonic game why software parity is my goal here.

http://3.bp.blogspot.com/-TV0WD2-kH...EGAGenesisClassics+2012-09-04+19-53-36-02.bmp

The water color is not a modulation of the color underneath with a tint color. It's a mapping from some color index to an alternative color to have the appearance of translucent water. The mapping function for tint blending, shown below:

gif.latex

where C is a True Color, to achieve the same visual aesthetic, is not quantifiable. We know what the end result should be, but the palettes used for mapping in the indexed function are not on a quantifiable, functional curve. There's a reason why fixed-func OpenGL doesn't look like software at all, and no amount of adjusting tints will ever approximate this well.

In a similar way, colormapping for lighting is not quantifiable.

SRB2 is and has always been about putting classic Sonic feel in 3D, and I think the software renderer's perceived faults with palettes actually accomplishes the visual aesthetic of class Sonic very well, particularly with 255-bright sectors. The reason for this, is Boom actually has essentially the same mapping function for translucency effects (which we inherent from in Doom Legacy for software).

Personally, I think tinting surfaces with true color blending actually washes out a lot of the color. It's appropriate for photorealism, but Sonic is not photorealistic. It's a very colorful game.

I do not think it is appropriate to get/keep photorealistic blends in the OpenGL renderer when the software renderer doesn't do it and maintains its visual color palette well without it.
There's a fundamental difference between the Sega Genesis and the Doom Legacy engine, though. The Genesis, at a specific hblank, switches to another hand-crafted palette. Doom Legacy, meanwhile, tints the entire 256-color palette and then automatically maps each entry back to the closest approximation from that 256-color palette. The two situations are thus incomparable: given that the Genesis palette is handmade and can reference colors not existent in the original palette, it can easily preserve all detail unless the designer explicitly chooses two palette entries the same color; Doom Legacy's palette, meanwhile, is autogenerated and will very likely cause loss of detail, given that A) the algorithm can only make a decision mathematically instead of aesthetically (machines aren't generally known for understanding aesthetics), and B) the end result palette is limited to a subset of the original 256-color palette, a restriction the Genesis palette doesn't have (as mentioned prior). I mean, if you take our 32-color gray palette range (0-31) and then map it to our 8-color fuchsia palette range (192-199), the pigeonhole principle makes it fairly plain you're going to assign more than one entry in the gray range to a single entry in the fuchsia one, losing whatever detail that had relied on those differences in shades of gray.

On that note I fail to see how Boom using the same lossy approach tinting is supposed to convince me this is a good idea. (I mean, you must've thought it would, you even bolded it!) It also only came about because they were stuck with an 8-bit color limitation that is irrelevant to OpenGL, and has the same "must map to the existing 256 colors" limitation that Doom Legacy's colormaps have (with an added plus and minus; the upside being that the user gets total control over what that mapping is, since it's not autogenerated, but the downside being you have to actually stand in the sector for the colormap to apply - it was only intended for fake floors to simulate water and such).

Your "washed out" argument doesn't even make sense. Look, here's GFZFLR02 and TAILSA2A8 under a 50%-transparent #0000FF tint, which I'm pretty sure is basically how Legacy auto-generates its colormaps. Left is untinted, middle is tinted in truecolor, right is then translated to SRB2's palette using the index with the closest color (again, like how Legacy auto-generates colormaps):

gfzflr02_bluetintedcluht.png

taila2a8_tintedf9uny.png


In both cases, the middle pictures preserve all the detail of the original detail while appropriately coloring things blue. The pictures on the right - which I'll remind everyone is what's apparently being aimed for here - show significant loss. GFZFLR02 had a good 10-or-so shades in it originally; now that's down to 4, losing a lot of the texture it had originally had. And TAILSA2A8; the underside of his tail went from an expected shade of purple to a dark gray, while the shine on his head is now a pale gray that stands out like an eyesore from the surrounding orange. And this is supposed to be better, how exactly?

At the end of the day, you're still continuing to argue that the correct approach here is to make OpenGL look worse in the pursuit of "palette parity" I don't recall anyone asking for, and then make those changes mandatory, screwing over those of us who stuck with OpenGL not merely because it has perspective correction, but because it looks better. Software was only recommended because nobody on the team was particularly good at keeping OpenGL up to date; that doesn't translate to "let's force all of its shortcomings into OpenGL" in the slightest bit.

What's next? Do we remove perspective correction from OpenGL, in favor of making all walls perfectly vertical, causing severe distortion when you look too far up/down? Software did it, so clearly it's the right thing to do! Parity!

(Also, never, ever use the Doom wikia. They moved to doomwiki.org ages ago. It's a long story.)
 
Status
Not open for further replies.

Who is viewing this thread (Total: 1, Members: 0, Guests: 1)

Back
Top