How hard would it be to add an option in video settings that switches between truecolor and limited color?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.
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..
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.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.
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.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!
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.me: the purple looking gfzrock that looks cool doesn't excuse the steel blue grass
me: thats also turquoise at the same time
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".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.
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.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..
Welcome to the SRB2 community. There's a good reason I ignore it when working and show things off as an afterthought.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.
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.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.
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.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.
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.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.
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?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.
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.Can we delete Tag yet?
犬夜叉;767023 said: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!
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:
*image*
In OpenGL, under the current truecolor implementation:
*image*
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.
*image*
*image*
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.
*image*
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)
Welcome to why I frequently do what I think is correct for the game regardless of the objections of the community.
犬夜叉;767023 said:Welcome to the SRB2 community. There's a good reason I ignore it when working
You're more than old enough that I shouldn't need to tell you this.
April 1st Grade A shit posting right here, I'll tell ya what.Why couldn't you *add* MD2 models to software?