OpenGL renderer overhaul progress
- Thread starter Eidolon
- Start date
- Status
So guys, some people are spouting bile and hyperbole here on both sides. Cut it down a few notches. Remember that "looks better" is an opinion, and people are going to disagree on that. If you have a disagreement, just calling people who think differently from you "wrong" is not going to lead to a good discussion. Pretending that your opinion is the ONLY opinion and the other side doesn't even exist is borderline infraction-worthy.
SRB2's visual design is intended to approximate the style of the 2D Sonic games in 3D. Our old, Doom-based engine is actually an asset here, providing us with an authentic, old graphical style from the early days of 3D gaming. Think of this like the intentionally retro styled games that have become popular recently, where the developers intentionally use dated visuals and styles to make the game look much older than it actually is. The only difference is that in our case the project is just so old that our engine isn't faking it; it really IS that old.
One of the tools to maintain our visual design is our limited palette. While the palette limitations started out as a simple technical limitation, at this point they're a major part of our visual design. If we want to use OpenGL as more than an unmaintained option, then we need to get it to actually implement the intended visuals for the game. If we can get OpenGL to render the way software looks, but faster and with less bugs, then that's what we want. If you don't agree with that, this game is open source and I'm sure that even if we don't provide more options at release, people who like shiny bells and whistles will make such things sooner or later.
SRB2's visual design is intended to approximate the style of the 2D Sonic games in 3D. Our old, Doom-based engine is actually an asset here, providing us with an authentic, old graphical style from the early days of 3D gaming. Think of this like the intentionally retro styled games that have become popular recently, where the developers intentionally use dated visuals and styles to make the game look much older than it actually is. The only difference is that in our case the project is just so old that our engine isn't faking it; it really IS that old.
One of the tools to maintain our visual design is our limited palette. While the palette limitations started out as a simple technical limitation, at this point they're a major part of our visual design. If we want to use OpenGL as more than an unmaintained option, then we need to get it to actually implement the intended visuals for the game. If we can get OpenGL to render the way software looks, but faster and with less bugs, then that's what we want. If you don't agree with that, this game is open source and I'm sure that even if we don't provide more options at release, people who like shiny bells and whistles will make such things sooner or later.
Root
-
How hard would it be to add an option in video settings that switches between truecolor and limited color?
I'm not a programmer so..
Jay
I'm lazy, let's face it
I could maybe see it becoming a command line parameter, but completely switching lighting modes on the fly in-game sounds way too daunting a task to even try to implement. Either way, I would be behind this.
Still, though, imposing an arbitrary limit like this because "the classics did it" just irks me.
Simply automatically tinting things doesn't work in all situations. A lot of visual effects that SRB2 and mods intentionally use are made possible entirely through how the software renderer handles things. Let's take an easy-to-understand example: a colormap of #808080Z. In software, this makes the whole area appear in greyscale:
In OpenGL, under the current truecolor implementation:
The former approach is a visual effect used intentionally in many maps, that the current OpenGL implementation flat-out displays wrong. There's no other sane way in current SRB2 to get a similar approach that only affects particular areas of the map. A similar issue can be seen in the THZ goop, with software users seeing a colormap that (very intentionally) brings everything into shades of lavender, while OpenGL users see a light tint if anything.
Now, fair enough, that case wouldn't be as bad if OGL simply displayed colormaps more vividly. It still wouldn't be accurate to the effect that's been designed for software mode without palletization, though.
I'm fully aware this is something that could be handled in true-color OpenGL through shaders, and I'm also aware that this still leads to certain color combinations looking pretty fuckin' ugly. You have a point there. That said, I'd like to get a screenshot that counteracts your example; colormap #0000FFM. A 50% blue tint with the way Legacy generates colormaps.
There is nowhere near the loss of detail you claim there to be. In fact, it's essentially the same as your middle example, except that the colormap generates better contrast. (Also, that purply GFZROCK <3)
In OpenGL, under the current truecolor implementation:
The former approach is a visual effect used intentionally in many maps, that the current OpenGL implementation flat-out displays wrong. There's no other sane way in current SRB2 to get a similar approach that only affects particular areas of the map. A similar issue can be seen in the THZ goop, with software users seeing a colormap that (very intentionally) brings everything into shades of lavender, while OpenGL users see a light tint if anything.
Now, fair enough, that case wouldn't be as bad if OGL simply displayed colormaps more vividly. It still wouldn't be accurate to the effect that's been designed for software mode without palletization, though.
I got curious and checked the source code. No, colormap generation is not a blind tint. It's actually pretty ingeniously-written; the brightness of the original color is used to multiply the tint color before blending, which means that colors keep their relative brightness regardless of how heavy the colormap tints the final colors. This is why the greyscale colormap effect above works. A colormap that tints the palette 100% in grey does not generate a colormap of 256 copies of #808080.
I'm fully aware this is something that could be handled in true-color OpenGL through shaders, and I'm also aware that this still leads to certain color combinations looking pretty fuckin' ugly. You have a point there. That said, I'd like to get a screenshot that counteracts your example; colormap #0000FFM. A 50% blue tint with the way Legacy generates colormaps.
There is nowhere near the loss of detail you claim there to be. In fact, it's essentially the same as your middle example, except that the colormap generates better contrast. (Also, that purply GFZROCK <3)
You're being an idiot. Palettization is an aesthetic choice (one that I'm aware not everyone agrees with, but a decision nonetheless). Perspective distortion is a limitation that everyone agrees is awful, and the one lone advantage (aside from performance) OpenGL has over software right now.
Root
-
From a steam chat:
There is nowhere near the loss of detail you claim there to be. In fact, it's essentially the same as your middle example, except that the colormap generates better contrast. (Also, that purply GFZROCK <3)
Also, again i'm not a programmer so I have no idea if this is even possible but maybe you could make it so OpenGL can render 512 colors while color blending, so it looks less crap while still having a limited palette like the Megadrive Sonic games.
I will remind you that there's a major reason we don't use a blue colormap over grass for exactly this reason. The water in GFZ is much clearer than the colormap in that shot as well, to prevent the weird blue line you see on the edge of the squares in GFZROCK. The palette is a tool we use for visual consistency, but we have to be sure to use it well or things look bad. Just like anything else, there are both positives and negatives to using a palette. Having to choose your colors more carefully is a negative.
The thing you seem to be missing here is that fury's made it abundantly clear that this is going to be a mandatory change. Given that, there's no room for multiple opinions, because there's only going to be one renderer - and since I'm the one with the opinion that's arbitrarily being thrown out here, you're damn right I'm going to fervently fight against that. Considering I want truecolor rendering, and that I consider that to be one of OpenGL's biggest strengths, it's insulting to have that opinion thrown out the window with "yeah but the software version adhering to a strict limit that doesn't even apply to hardware rendering doesn't look like that so we're going to deliberately gimp the hardware branch because "parity" so screw you".
Seriously, ever since GLQuake back in 1996, it's generally been accepted that hardware rendering is better than software rendering, with higher color depth being one of the biggest boons. When the occasional detail was found that the software renderer had that the hardware renderer was missing (eg: Quake's overbright lighting and fullbright palette range), those missing features were later reimplemented without losing those key benefits that the hardware renderer had; they didn't throw the baby out with the bathwater and make the hardware renderer an exact replica of the software renderer, complete with all its downsides. Literally no 3D game that has a hardware renderer has ever done this. Hell, Unreal Engine's software renderer does the literal opposite, trying to avoid it by using some weird dithering effect to look closer to truecolor. Justifying this change with "we look like authentic old 3D games!" isn't going to cut it with me, given that.
And saying correct truecolor rendering is going to be relegated to some niche spinoff executable is really not calming me down, to be blunt; it's just confirming you fully intend to do what I've been arguing against the entire thread.
Like, yes, colormapping in OpenGL is broken. I get that. But there has to be a way to fix it without making the entire goddamn hardware renderer behave identically to the software renderer, because at that point you've ruined one of the biggest boons the hardware renderer had. (And hell, there's already been work on implementing perspective correction to the software renderer, so there's that, too.)
It should just be an if/else statement. Seriously, if something like GZDoom can change lighting settings on-the-fly, there is nothing stopping SRB2 from doing the same, which makes the resistance to doing so all the more infuriating.
ShadowHog, for the record, it's a little more than an if/else statement. And I'd appreciate it if you wouldn't backseat program. I'm uploading Doom textures to the GPU as red channel-only 8-bit textures such that the red channel in the shader exactly represents the U component of the palette texture. In order to switch entirely to fixed-func, we have to reupload all the textures currently in use back to the GPU after converting them to true color from the user code-side palette. This is a little difficult to manage because the hardware renderer's mipmap handling code does not account for reuploading of textures. I can't imagine it would be difficult, but it's not trivial.
The better solution would be to simply write an alternative shader that doesn't use the full colormapping system, only uses it to index the palette for textures and then has a general lighting and blending model otherwise.
I never said you wouldn't be able to replace the shader used, I only said I wouldn't make it an option to switch to actual fixed function code -- the former represents a definitive performance loss and there is no reason to keep using it if you have GL2 hardware support. In fact, I intend to make the shaders lumps so that WADs can replace them.
The fact of the matter remains, I fully intend to keep the software-style colormapping the default shader set when using OpenGL mode. This is mainly backed by the fact that software will not ever work well enough to be usable on Android due to low CPU-GPU bandwidth on most devices. Getting the Android port running is my ultimate goal before 2.2's completion, and software renderer parity in OpenGL is a crucial component of making that happen. In addition, I completely agree with Mystic's sentiment that no matter what people think "look better" (and honestly, I think they're wrong in this context), the colormapping look is completely intentional and current OpenGL is definitively not doing the job correctly. We are not Doom. I do not care what the Doom community is doing compared to SRB2.
On a side note, it's highly discouraging for me when I spend days researching how to implement this, provide a proof of concept, and get nothing but complaints.
The better solution would be to simply write an alternative shader that doesn't use the full colormapping system, only uses it to index the palette for textures and then has a general lighting and blending model otherwise.
I never said you wouldn't be able to replace the shader used, I only said I wouldn't make it an option to switch to actual fixed function code -- the former represents a definitive performance loss and there is no reason to keep using it if you have GL2 hardware support. In fact, I intend to make the shaders lumps so that WADs can replace them.
The fact of the matter remains, I fully intend to keep the software-style colormapping the default shader set when using OpenGL mode. This is mainly backed by the fact that software will not ever work well enough to be usable on Android due to low CPU-GPU bandwidth on most devices. Getting the Android port running is my ultimate goal before 2.2's completion, and software renderer parity in OpenGL is a crucial component of making that happen. In addition, I completely agree with Mystic's sentiment that no matter what people think "look better" (and honestly, I think they're wrong in this context), the colormapping look is completely intentional and current OpenGL is definitively not doing the job correctly. We are not Doom. I do not care what the Doom community is doing compared to SRB2.
On a side note, it's highly discouraging for me when I spend days researching how to implement this, provide a proof of concept, and get nothing but complaints.
Last edited:
K.S.
Formerly Inuyasha, Retired Staff
Welcome to the SRB2 community. There's a good reason I ignore it when working and show things off as an afterthought.
And hahahah, I haven't even mentioned how I want complete render parity, including the removal of MD2 models and any other additional "features" present in OpenGL!
Wait a damn minute here. You're comparing the advancement of game technology in the 90s from software to hardware renderers in general to a stylistic choice in a game intentionally trying to be retro themed? At the time in 1996 we were just moving from the 2D era into the 3D era, where the goal was realism. Of course people at the time wanted true color at the time! It was the era of the PS1 and gritty realism in prerendered graphics. When your goal is trying to get closer to photo-realism, of course true color is the way to go.
This is not that. This is a stylistic choice almost two decades later in a world where true color is used everywhere in games. Whether or not you agree with that stylistic choice, there is absolutely no correlation between the time when true color gaming came into being and today.
Now this is even more of a dead stop. There are a lot of far more important features that OpenGL rendering provides that are infinitely more relevant to the average user than true color rendering.
- Hardware rendering uses the graphics card instead of a single core of a multi-core processor. This means OpenGL provides far better framerate for most players, and at higher resolutions.
- Hardware rendering is far better supported on modern operating systems than software. Again, this means OpenGL provides better performance than software in most situations.
- Hardware rendering doesn't have any problems with high view angles, slime trails, and other such problems software does.
This small quote, right here, distills your argument FAR better than any of the borderline offensive walls of text you've thrown out. Don't take an argument that you don't agree with as an attack on you. Don't call catering to an audience that isn't you a fool's errand. You're more than old enough that I shouldn't need to tell you this.
Welcome to why I frequently do what I think is correct for the game regardless of the objections of the community. Can we delete Tag yet?
Look guys, I really don't want such an amazing project to die on page 2. Can we just ignore the silly truecolor thing for now on a game that's meant to look like it just walked out of the 90s so Furyhunter can continue getting to the meat of the operation?
Fuck true-color for now, that can be done when this is basically stable and a lot more complete.
Fuck true-color for now, that can be done when this is basically stable and a lot more complete.
Last edited:
Zwip-Zwap Zapony
Member
Yes. Why? We have Lua now. That means we can "easily" recreate it without modifying the source code of the game itself. Which we didn't when Chaos was removed.
Back on topic: An OPTION would be nice. If not, then the ability to make shaders in Wads (as Fury already said was wanted to be implemented), with the ability to replace the software shader with absolutely nothing, leaving it true-colour, without that triggering as "modifying the game".
srb21103
Me!
EDIT: The original post was in poor taste. You can view it below if you so wish.
Why couldn't you *add* MD2 models to software?
To me, it seems SRB2 is coded by a bunch of lazy developers who can't even agree with each other, and aren't particularly good at coding. Why else would you choose to use an existing engine in the first place, and then decide it's time to overhaul the OpenGL rendering over a decade later? But I digress.
If this *is* implemented in SRB2, someone could just make their own fork without it.
Therefore, I would suggest running a poll to see if the community want this "feature" in vanilla SRB2.
犬夜叉;767023 said:
Why couldn't you *add* MD2 models to software?
To me, it seems SRB2 is coded by a bunch of lazy developers who can't even agree with each other, and aren't particularly good at coding. Why else would you choose to use an existing engine in the first place, and then decide it's time to overhaul the OpenGL rendering over a decade later? But I digress.
If this *is* implemented in SRB2, someone could just make their own fork without it.
Therefore, I would suggest running a poll to see if the community want this "feature" in vanilla SRB2.
Last edited:
I can't wait to see the fruits of this project! I have many aesthetic disagreements with OpenGL and- truth be told- I've often asked the devs why they don't just kill it outright. If they can bring it to parity with Software, it might actually be nice to look at, AND give my poor processor some slack.
Death to MD2s.
Death to MD2s.
Comparing the way software does colourmapping to the way current OpenGL does it is a completely pointless and silly thing to do, considering OpenGL does currently do it completely wrong. If it was doing it correctly it would give very similar results without the limitation of the palette.
gregory_house
Also known as TemporaryAl
犬夜叉;767023 said:
This is ridiculous, and I really wonder how you think this game has magically kept itself alive over the years, because clearly the community that plays it is no important factor, seeing how much merit and attention you're giving it here. Mystic's "for the game" in particular makes it sound like the game is being developed for itself rather than the community.
Having to put up with so many recent one-sided choices is getting hard for a lot of people.
I can totally understand the concept of "looking like a classic Sonic game" and blah, if that's what this game should have been from the start, I'm just disconcerted by how you still decide to pursue that goal even when it's clear that a large part (I don't honestly know how large, but seeing the number of complaints that appeared here in so little time I'd suspect it's more than just a handful of people) of the community considers what you see as some sort of mistake to be "one of OpenGL's biggest strengths".
I can also see why it would be discouraging to receive "nothing but complaints" after working hard on this project (by the way, the part regarding CPU usage optimization is just great to hear), but really, this is to be expected if you start working on something and just assume everybody wants that something implemented in the game instead of either asking (although seeing the comments made here about the community, I feel like that would be a heresy there) or at least starting a project in hopes of addressing already existing complaints (the SDL2 build or, why not, the second part of this project even; while nobody I know of has complained about how OpenGL looks until now; PS: okay, apparently toaster has).
If the ideal of just being a 3D rendition of a classic Sonic game has so much value to you, and apparently it does, then by all means go ahead and implement all the parity you'd like (you most certainly will, this being your game and not mine, I can't blame you for that, since that's the way it's really meant to look like), but as already requested more than once in this thread, please, keep the old OpenGL look at least as a non-default option, because I'm assuming, and I hope I'm right, that as game developers what you really aim for is for this game to be played and liked by as many people as possible, and that you're willing to sacrifice at least a slight bit of that "classic Sonic game" look for this (and not even that, with the default settings).
Last edited:
I will not make fixed function an option for people who have computers that support GL2. There is no reason for them to be using it.
You will be able to reimplement the old look by writing a set of fragment shaders replicating the effect you want. Jesus Christ.
You gotta wonder why this game has a problem with keeping programmers interested in developing for it. Maybe it's because any time anyone introduces anything, the forums collectively shit the bed over it.
You will be able to reimplement the old look by writing a set of fragment shaders replicating the effect you want. Jesus Christ.
You gotta wonder why this game has a problem with keeping programmers interested in developing for it. Maybe it's because any time anyone introduces anything, the forums collectively shit the bed over it.
Last edited:
April 1st Grade A shit posting right here, I'll tell ya what.
Shaddy the guy
Professional ass-merchant
Oh, so we started a day early again.
- Status