OpenGL renderer overhaul progress

Status
Not open for further replies.
So, bad news bears. Well, kinda bad news bears.

The most recent commit to my cleanup-opengl branch.

The good news is, my vertex array approach vastly, significantly, enormously (we're talking like 10x framerate up to 600fps) improves performance in ERZ2 on my uncapped branch.

The bad news is,

1. It breaks basically every special effect (lighting, colormapping, everything) in OpenGL.
2. Jesus christ holy fuck no I am not working on that renderer anymore. It's BAD. REALLY BAD.

Unfortunately, I will have to rewrite the entire renderer from scratch to just make things work. Leaving the fixed function pipeline backend as an option is absolutely out of the question now, if I were to continue with this. It's bad, broken, and an unmaintainable mess.

EDIT: Clarification, I am investigating a full rewrite of the OpenGL renderer, but it will take time to get any results. I am looking at what other engines are doing and may end up doing something similar to the Doom iOS approach.
 
Last edited:
Shadow Hog said:
This insistence that the palette limitations were the intent all along is, frankly, a phenomenon new to this sudden push for a paletted hardware mode. I have never seen any attempts to justify it before now.
Click to expand...

A fangame started near/basically in the 90s looks like a 90s game and wants to keep consistent with how it's always looked!
Joseph-oh-my-god.jpg
 
I will be managing a technical document on the gitlab wiki which is located here.

The plan right now is to model the new renderer around Strife: Veteran Edition's. It's a fairly flexible system which will hopefully enable us to optimize and offer different rendering paths based on system availability (GL 1.5, GL 2.0, GLES 2.0, etc). The render endpoints will rely on these shaders for the first implementation.
 
Boinciel said:
I'm just going to single this out as a really great example. Mega Man 9 doesn't just limit the colours to a palette, it also emulates sprite flickering to get an authentic Mega Man NES feel. On the NES, too many sprites onscreen would cause sections of sprites to not be drawn every other frame (you can see this in Sonic games too if you use debug and place a bajillion rings!). Why did Mega Man 9 go so far as to replicate this? To get the feel absolutely perfect, and to put forth exactly the image they were trying to project.
Click to expand...

...Which was actually toggleable, for people that wanted "legacy mode" or not, allowing for choice.

Either way, I feel that the addition of this to the game is a decent idea, but I agree with Shadow Hog that it would be best if there were an option to use true-color mode along with the palleted mode, even if the paletted mode is the default selection.

Edit: considering that openGL will need to be replaced anyways, the choice between truecolor and paletted is less needed by me, as I would prefer stability over anything else. However, if software paletted mode can be done as a selectable shader, all the more power to you.
 
Last edited:
Mystic said:
It was not the intent all along. It became the intent around the time we changed the palette for 2.0 during development and dropped OpenGL completely for software, which from a visual design perspective we continue to do.


I'd argue that when things get heated to the point where hyperbole and angry posts are being made, things have gone too far and we all need to take a step back and calm down. This is true here on the forums, in #srb2dev, and wherever angry arguments are being made. Just because we fail sometimes privately as well doesn't make failing any less of a problem. =P
Click to expand...
Alright, fair enough. Apologies for any heated remarks made. And for what it's worth, I still support the paletted hardware mode from an intellectual standpoint - I even believe there are people in the Doom community who would be interested in having such a thing for that game. I just (evidently rather vehemently) disagree that it looks better.

...so with switching to Strife: Veteran Edition's renderer, are we basically switching from Doom Legacy's renderer to Chocolate Doom's? (After all, Strife: VE was based on Chocolate Strife, IIRC. I mean, Quasar expanded upon it considerably, yes, since Chocolate Strife didn't even have hardware rendering or even support for resolutions higher than 320x200, but still!) I also assume there's no intention to support its lightmapping system (I mean, that was never in the plans for SRB2 in the first place).
 
Iceman404 said:
A fangame started near/basically in the 90s looks like a 90s game and wants to keep consistent with how it's always looked!
Joseph-oh-my-god.jpg
Click to expand...

So, we're in 2015, and for the sake of the game being started in the 90s, it has to maintain the looks of old crappy computers with old crappy graphics cards?

I'm sorry, but does Unreal Tournament 4 have the same graphics as Unreal Tournament GOTY? Nope. And yes, I know they're not the same game, but if you see what I'm getting at, hardware is advancing, so we should really take advantage of this.

Yes, I do have a thing for good graphics, I choose OpenGL over Software for two main reasons:
1) OpenGL looks nicer most of the time
2) Software seems to not run as smooth on high-end machines.

I always choose full rotations when it comes to 2D fangames, as oppose to legacy rotations too.
 
Last edited:
hitkid61 said:
So, we're in 2015, and for the sake of the game being started in the 90s, it has to maintain the looks of old crappy computers with old crappy graphics cards?
Click to expand...
Yes. It should keep looking like how it was meant to look. Crappy is subjective because there are several times already pointed out in the thread of when software actually does its visual job better than OpenGL because the game intended for it to.

I'm sorry, but does Unreal Tournament 4 have the same graphics as Unreal Tournament GOTY? Nope. And yes, I know they're not the same game, but if you see what I'm getting at, hardware is advancing, so we should really take advantage of this.
Click to expand...

Thanks for shooting your own point down, now go make SRB5 and tell us all about it! If you start it, you can make the game in mind with less limitations from the start!

I won't reply any further, I've said the same thing several times now. But let us know how it goes!
 
Last edited:
hitkid61 said:
So, we're in 2015, and for the sake of the game being started in the 90s, it has to maintain the looks of old crappy computers with old crappy graphics cards?

I'm sorry, but does Unreal Tournament 4 have the same graphics as Unreal Tournament GOTY? Nope.
Click to expand...

If you want high end graphics, go play Unreal Tournament 4.
 
I like the idea of this project, Furyhunter, keep it up.

I wonder though -- if the truecolor power of OpenGL can also be leveraged while still achieving what you desire -- for example, in a colormap that causes a reduction in color depth (like the water ones shown on previous pages), rather than doing a remap into an existing palette, couldn't a whole new #0303BBZ palette be generated with a 256-color span, and each color remapped to the closest luminance? This would avoid the washed-out look where multiple colors remap to the same palette index.
 
SSNTails said:
rather than doing a remap into an existing palette, couldn't a whole new #0303BBZ palette be generated with a 256-color span, and each color remapped to the closest luminance? This would avoid the washed-out look where multiple colors remap to the same palette index.
Click to expand...

This is exactly what needs to happen. There is one thing in SRB2 as we know it which is an outright palette change and "not quantifiable", and that's just the brief flashes for teleporting and armageddon shields -- and even that was an automatically generated color tinting, not something that an artist sat down and individually determined the most beautiful possible colors for. It's incomparable.

The current OpenGL renderer is as far from what we speak of when we say we'd prefer a "true color" implementation as you can get, too, so you can't really compare that either. The current gr_fog color modulations are only the best I could do in ancient OpenGL 1.1 when I was like 19. It's terrible, I know.
 
You know I wouldn't have a problem with true color if it looked nothing like current opengl does. My problem with it is the fact that...

Okay so in software, when something gets dark it ONLY goes down a shade in brightness, retaining its tone because the palette is hand picked that way. It gives a very nice vibrant colorful look even when areas dim out.

On the other hand, OpenGL does this thing where when something gets dark its almost as if its just tinted with black. The colors get washed out and very dry, the appearance in comparison is that it almost looks dead whenever any sort of lighting comes into play (That and the constant gradient shading rather than sharp value changes that actually fit with the 2D sprites like a glove).
 
Yeaaah, that's because OpenGL 1.1 only has "subtractive" color blending. It literally can't add color or maintain luminescence and is just "tinting black". You can guess how it tries to do colormaps that makes it fail so hard: By subtracting different values from R, G, and B. X_x;

That's not how it should be done and we know it. :(

Incidentally, if you ever look at a game like Diddy Kong Racing DS and wonder why it gives you RGB sliders for your yellow vehicle and you can't actually get any blue out of it? That's because it's using this shitty method of color blending on a full-color texture.
 
Holy hell my suspicions were actually accurate? That's crazy. If we could have true color with software's actual lighting style and working colormaps I'd be pretty stoked.
 
hitkid61 said:
So, we're in 2015, and for the sake of the game being started in the 90s, it has to maintain the looks of old crappy computers with old crappy graphics cards?

I'm sorry, but does Unreal Tournament 4 have the same graphics as Unreal Tournament GOTY? Nope. And yes, I know they're not the same game, but if you see what I'm getting at, hardware is advancing, so we should really take advantage of this.

Yes, I do have a thing for good graphics, I choose OpenGL over Software for two main reasons:
1) OpenGL looks nicer most of the time
2) Software seems to not run as smooth on high-end machines.

I always choose full rotations when it comes to 2D fangames, as oppose to legacy rotations too.
Click to expand...

That's a terrible argument, especially when you've seen the shit truecolor creates. It looks like a kid made a drawing, colored it with colored pencils, then spilled purple cleaning chemicals all over it. It looks like, well, shit. But I guess that plain, lifeless, 'greydients' (I say that because it doesn't actually look grey) are what you think looks better than an art style that developers and artists have taken years to perfect. You wouldn't know that because you're too busy not thinking logically.

Also if the grey pallet got chopped in half alongwith the brown pallet (Nobody uses the whole thing, I have to work in steps of fucking four) I'd be happy.
Oh and reduce the blue pallet to one line. Why are they so long anyways?
 
I think the main idea with Orange/Blue/Red all having ~24 colors each is because Sonic, Tails and Knuckles use those colors particularly ...so naturally they'd have some priority!

That aside, SRB2 is not comparable to Unreal Tournament 4 in any case - different genre, different influences, different directions, and different intended art style!
 
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.
Click to expand...

Erm...
A option to still use software will be avaliable... right?!
 
Hardware rendering is:

simpler to implement and maintain
more flexible for future development
scalable (ever tried to play srb2 at 1920x1200? it's barely playable by even the fastest processors)
easier for people to customize
parallelized on 99% of computers implicitly, even intel drivers
faster for the vast majority of users
the only way we're ever going to get reasonable performance on Android
 
Furyhunter said:
Hardware rendering is:

simpler to implement and maintain
more flexible for future development
scalable (ever tried to play srb2 at 1920x1200? it's barely playable by even the fastest processors)
easier for people to customize
parallelized on 99% of computers implicitly, even intel drivers
faster for the vast majority of users
the only way we're ever going to get reasonable performance on Android
Click to expand...

My only problem with hardware is that I don't have a graphics card. That's why I didn't like you decision to replace software with OpenGL.
 
If I've gotten it to work at 35FPS on a pretty old PC with only an Intel G43 integrated graphics chipset and no dedicated GPU, it shouldn't be a problem for you either, especially since newer implementations of hardware rendering will probably have way better performance when they're made.
 
Status
Not open for further replies.

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

Back
Top