Alright, I'm gonna try explaining my thoughts on this manner in an organized, concise way. I'm not going to bother quoting individual posts because that leads to directly addressed question-and-answer dribble that fails to capture the grand scheme of things.
The reason the OpenGL renderer is not officially approved (I'd like to avoid the term "supported" here, because that leads to ambiguity) by the development team is for one simple reason: The OpenGL renderer does not implement all of the Software renderer (the
correct one, the one used for reference) features, or otherwise implements them incorrectly. This includes considerably minor things, such as the often mentioned sprite billboarding effect, but actually much more severely gimps how a lot of things are displayed, which I'm surprised NOBODY seems to notice.
The OpenGL renderer does not correctly render:
- Distance lighting
In Software, the camera acts like a light source. When the sector light level is not the maximum, the area immediately around the player's viewpoint is shown as being at maximum brightness, with everything being darker the farther they are from the player.
This is the effect that a lot of people are experiencing when they note how much more vivid a level looks with Software than the dull, lifeless appearance of the OpenGL renderer.
- Colormaps
Colormaps are supposed to take the colors used in the scene and replace them with colors of an equivalent brightness from a predetermined gradient. The normal colors are effectively mapped to a different set of colors, hence the term, colormap.
OpenGL fakes this by instead using transparency to tinge everything with the colormap's hue, which makes the colors look off. Simply hop into GFZ1's pools of water in both renderers and you'll easily be able to notice the drastic difference -- while Software maps the colors to an azure tone, which makes the walls take on a creamy, sepia tone, OpenGL simply makes the scene slightly darker and hardly touches the colors due to the weak strength of the colormap.
Another thing colormaps can be used for is to change the distance lighting color from black to something else, which can be used to create various effects such as white fog or an orange, fiery haze which glows in the distance. The OpenGL renderer simply flat out cannot do this due to its inability to handle distance lighting, which is what breaks several colormap effects like the alarm in THZ2. JTE started implementing this using OpenGL's fog, which looked promising, but he never really nailed it, leaving us with horrible off-color water when gr_fog is on.
- The sky
The sky is drawn in a special way in Software, something which I believe cannot be accurately mimicked in OpenGL without the use of shaders. Software scans for linedef textures which are blank and should display the sky, and draws the sky on those linedefs albeit in a way that perspective does not affect the drawn graphics. This is one of the novelties of drawing every individual pixel on the screen, you get to do stuff that isn't quite logical. In fact, this occasionally ends up in oddities where you can see the floor or ceiling of the open-air sector, but some of the linedefs force the sky to be drawn in front of the sector's flats.
What I think the OpenGL renderer does is simply draw the sky before drawing all the level geometry on top of it. This works to some degree, but now you can't count on using sky linedefs to cover everything that's behind them like they do in Software. You can see this backfiring at several different points in OpenGL where a ceiling is lowered to make a cave, but from the outside you can still fly higher than the top of this wall. You'll notice that you can peek into the sectors which are behind it, and actually see them perfectly as though their ceilings had been removed. This is visible in GFZ1 in the water cave right at the start and later on in the token cave.
Furthermore, OpenGL draws the sky texture itself in an incorrect way. Software does a neat blit trick where 256 horizontal pixels are stretched to 320 pixels on-screen via reverse barrel distortion, which gives the sky a bizarre, cylindrical shape, keeping the aspect-ratio at the center of the screen but stretching it near the edges. The OpenGL renderer forgoes all this and simply stretches the sky into a flat, ugly rectangle.
OpenGL also does not support small skies correctly, which is ironic since very rarely does anyone make a full 360º sky. If you boot up GFZ and slowly turn around in circles, you'll see that the sky kinda tilts from one side to the other, then it rapidly starts scrolling to one side, then stops and starts tilting again, rinse and repeat. What the fuck?
- Sprite splitting
This one's simple. When a sprite is halfway inside an FOF with a special flag, Software splits the sprite in two halves, so for instance, the top half can be drawn normally because it's above water, but the bottom half gets affected by the water's colormap because it's inside. The OpenGL renderer simply does not implement this and paints the whole sprite even if only its toes are wet.
The list goes on. Making the OpenGL renderer the standard right NOW would be an immense mistake, because even though you might like all the shiny glitter a proper 3D renderer comes with, the truth is that you'd be breaking half of the visual effects in the game, which is simply inexcusable.
Should one day all these faults be fixed, then the move to OpenGL would be much more sensible, but still without complete peace of mind.
While OpenGL runs in true color, 32 bits per pixel, Software forcefully runs at 8bpp color. This is what's binding us to a limited 256-color palette. If we made the switch and went OpenGL only, then why are we forcing sprites and textures to use only 256 colors when lighting, fog and colormaps can use all the RGB spectrum? It would make sense to get rid of the palette and start using true color graphics. However, to do this, we essentially need to get rid of the graphic formats SRB2 uses and implement brand new ones based on PNG or something. But if we're doing this, then why not take the opportunity to increase the resolution of the textures? We're not running the game in 320x200 anymore, so those pixels become awfully apparent when seen up close. While we're at it, we could add MD2 models, slopes, dynamic lighting and reflections. Why are we using the WAD format again? Let's switch to 3D models and actor scripts.
This is the slippery slope SSNTails is talking about. If you're dropping one ancient part of the engine, the next one is only going to seem more glaringly obvious. At what point do you stop and say "Okay, we've updated it
enough."?
That's not to say I agree 100% with this sentiment. I like the prospect of having slopes in the game because they would replace the tiny staircase method, making existing maps more appealing and less taxing on the hardware, and making future maps more likely to use slopes to create vertical variation, instead of having to resort to springs or series of tedious jumps.
However, on the flipside, as SSN has mentioned in the past, if you're adding honest-to-god slopes, then you're going to end up opening a big can of worms. If you simply add the slopes as cosmetics, and don't change the physics, then Sonic standing perfectly straight on a 45 degree slope just isn't going to look as believable as standing on a 45 degree flight of tiny stairs.
Conversely, if you add decent slope physics, then a) you're back on the slippery slope, why not just switch to a brand new vector-based engine instead of converting from orthogonal to vector to orthogonal, and b) you're fundamentally changing how SRB2 plays. Quite personally, I don't want that to happen. I would love to play a free-roaming 3D Sonic game with all the crazy half-pipe flingy stuff of the classic Sonic games (where the hell is wizard, man), but I also appreciate what all SRB2 could accomplish without, gasp, Sonic's trademark mechanic.
Summing it all up, am I in favor of switching to OpenGL exclusively? Yes. Am I in favor of adding slopes? Yep. Am I in favor of doing it right now? Not by a long shot.
