Big Switch to OpenGL Exclusive?

Status
Not open for further replies.

VelocitOni

KartKrew Dev
Sonic Team Junior
Kart Krew™️
I made this topic to not clutter the SRB2 Community Build one that was already filling up with this discussion.

So my question is, has Sonic Team Jr. considered making SRB2 OpenGL exclusive? With SRB2CB, we've seen that SRB2 can totally be much more than it is right now if it supported OpenGL only. It supports skyboxes and slopes, it's in real 3D and supports 3D objects, and it has a much better frame rate and rendering quality; it basically can do everything Software Rendering can and so much more. Why has the team decided to stick with a 10 year old render that's only hindering their capabilities for so long when people these days have the technology to easily run things like OpenGL?
 
Why has the team decided to stick with a 10 year old render that's only hindering their capabilities for so long when people these days have the technology to easily run things like OpenGL?

Well some people have such crap computers that they can't run SRB2 in OpenGL. Besides, everything is fine the way SRB2 is now. Why would the team sacrifice their time to rewrite SRB2's code for slopes and skyboxes? It's two things to cause the devs a shitload of work...
 
I think slopes could benefit 2D levels. For example, you could make a pretty detailed background with loops and curves for eye candy. Remember that 2D Green Hill Zone? Those loops bring back horrors!

Oh, it also fully supports polyobjects without making them look ugly.
Edit: Why not add Kalaron to the SRB2 team. He/She obviously knows what he/she is doing and could make SRB2 a lot better then it is at the moment.
 
Well some people have such crap computers that they can't run SRB2 in OpenGL. Besides, everything is fine the way SRB2 is now. Why would the team sacrifice their time to rewrite SRB2's code for slopes and skyboxes? It's two things to cause the devs a shitload of work...
They wouldn't have to rewrite the code if they just switched to OpenGL for slopes, your thinking ZDoom. And it wouldn't cause the devs much work since they don't HAVE to use them, but the community can on Vanilla SRB2 with more support. It's more of a benefit than a loss, if not a loss at all.
 
I honest doubt this is going to happen, given what SSNTails already said on the SRB2CE thread. (http://mb.srb2.org/showthread.php?t=35949&page=5#82)

It took quite long enough (Almost 12 years) for SRB2 to come this far in software mode alone. Just changing to OpenGL now would probably change everything about SRB2, and would require a LOT of work for the developers.

In fact, I just thought of a better idea: why not make a separate download for SRB2 as an OpenGL exclusive, and the other be the old software version? Perhaps Kalaron could work on the OpenGL version while the rest of the devs make the software version...

What do you guys think?
 
Don't act like the official dev team is the only group of people that can make it happen.

We already have all the tools needed to make a complete sloped, skybox, reflections, and polyobject filled rendition of SRB2 ourselves.

Stop complaining and try to do stuff yourself, it's not hard, you just have to want it.
 
OpenGL begets slopes begets models begets entire level redesign begets deciding it better to go true 3d begets rewriting gameplay code begets changing to a true 3d map format begets...hey, wow. It would have been quicker to start with a new engine and port the content!

Like Megaman 9 & 10, SRB2 styles itself after a videogame 'era', creating a belivability of the universe it resides. You don't expect to have slopes, 3d models, and full orchestral music in Megaman 9 & 10, now do you?

If you feel SRB2's content itself doesn't need to update with the times, then you're just going to end up with one big 'engine test' thing like every other joe schmoe out there (Sonic GDK, Ashura Dark Reign, Egg Engine, Blitz Sonic, Sonic Fan Remix, etc.). The idea was to make a GAME, not an ENGINE - and frankly, that's what has always put SRB2 above the rest. I've always considered the editing capabilities 2nd priority.
 
Last edited:
I meant that everyone needs to stop complaining about how other people are doing stuff wrong and try doing things themselves instead.

Unlike other games, all the stuff needed to keep working on SRB2 is there, it's just that most(but not all) of the community doesn't feel like doing things or doesn't have the drive to make really good content.

Also, for the work it would take for the developers to re-do the official levels:
  • A) We can have a community driven remake of SRB2's default levels
  • B) People just leave the default SRB2 levels as they are and make use of OpenGL only stuff in mods
  • C) The official devs can merge the official levels with skybox/slope-based remakes if they're good enough

The developers don't have to do everything themselves.
 
Well some people have such crap computers that they can't run SRB2 in OpenGL.
Or recent computers screwed over by terrible equipment. The Intel card in my 2008 laptop is supposedly "up to date" on its' drivers and OpenGL refuses to run faster than 3 FPS.
 
OpenGL begets slopes begets models begets entire level redesign begets deciding it better to go true 3d begets rewriting gameplay code begets changing to a true 3d map format begets...hey, wow. It would have been quicker to start with a new engine and port the content!

If you feel SRB2's content itself doesn't need to update with the times, then you're just going to end up with one big 'engine test' thing like every other joe schmoe out there (Sonic GDK, Ashura Dark Reign, Egg Engine, Blitz Sonic, Sonic Fan Remix, etc.). The idea was to make a GAME, not an ENGINE - and frankly, that's what has always put SRB2 above the rest.

A port requires starting from scratch, a rewrite can keep all the content that's already there and just build on it.

Instead of starting over, we can just improve what we already have - With a serious rewrite of the engine, there can finally be a complete game that also doubles as a decent Sonic engine.

We can always rewrite the collision system to replace the blockmap while keeping backwards compatibility with the wad format AND we can make a new map format when the 2D map editing with Doom becomes too cluttered.

(and of course, with "we" I don't mean the official devs, I mean whoever wants to try this insanity :P )

A rewrite is always easier than a port.
 
The idea was to make a GAME, not an ENGINE - and frankly, that's what has always put SRB2 above the rest. I've always considered the editing capabilities 2nd priority.
And yet we had to make do with as little as 6 full acts for about 10 years, two of which have since then been removed entirely. :P

Not that I'm anywhere close to disagreeing with you. But if there's one thing that bugs me about the software mode is the ancient unpredictable crashes that occur because that renderer was only intended to draw the simple geometry and small scope of Doom levels.

My dream would be one where the OpenGL renderer were refined to a point where you couldn't tell the difference between it and the software render, except that it's in true color and as such gets rid of the ugly color banding effect that plagues some distance lighting and colormap effects.

But unfortunately for me the majority of people are content with replacing the charming, hard-worked 2D sprites with soulless 3D models, adding motion blur and pointless particle effects. Le sigh...
 
My dream would be one where the OpenGL renderer were refined to a point where you couldn't tell the difference between it and the software render, except that it's in true color and as such gets rid of the ugly color banding effect that plagues some distance lighting and colormap effects.

You're right. You're so right, OpenGL should be 1:1 with software mode, I should never forget the original charm that makes SRB2 what it is, software's look is a big part of the experience.

I'm trying to make OpenGL as close to software mode as possible, I suppose maybe most of the features are in there, but the actual look is what it needs the most now.

I think the only way to truly make a perfect OpenGL mode is to actually use advanced OpenGL effects such as pixel shaders, fortunately, even the most basic of modern computers are becoming able to handle those kinds of things more and more each day.

So, is the real concern is: Can we do it? Or do we have to wait for the few people that can't run it?
 
The problem is, none of our current dev team can really fathom OpenGL mode; Kalaron is the only one that seems to have it down really well..
 
The problem is, none of our current dev team can really fathom OpenGL mode; Kalaron is the only one that seems to have it down really well..
Autosaver said:
Edit: Why not add Kalaron to the SRB2 team. He/She obviously knows what he/she is doing and could make SRB2 a lot better then it is at the moment.
Oh and I totally agree with the point of the community actually contributing to SRB2's development. It could actually speed things up ya know?
 
Lots of great comments here. First off, I want to commend Kalaron on his work - the progress he's made so far is not easy. The following may sound critical but I just want to provoke discussion.

Believe it or not, the choice to not go OpenGL-exclusive is not tied whatsoever to some people's machines not being able to run it.
---------------

most(but not all) of the community doesn't feel like doing things or doesn't have the drive to make really good content.

Kalaron said:
We can have a community driven remake of SRB2's default levels

...Contradictory statements??

Kalaron said:
  • B) People just leave the default SRB2 levels as they are and make use of OpenGL only stuff in mods
  • C) The official devs can merge the official levels with skybox/slope-based remakes if they're good enough

Seems like a good idea, but if you want to move to pinball physics and a true vector based system, keeping the old stuff isn't going to be possible. The gameplay and player movement is going to drastically change that will break existing level designs.


You mentioned replacing the blockmap. Why? What do you propose replacing it with? How are you going to handle the player moving super fast? Going 60 FRACUNITs/tic is already really pushing it (for perfect collision, you should only move radius/2 per tic). If you place rings on those slopes where you allow moving 120 FRACUNITs/tic, you'll notice that you run right through them...

Are you going to reimplement a collision and response system? How? Keep in mind that when standing on a slope, the object shouldn't be treated as a vertical cylinder... it should be rotated relative to the slope. Checking XY bounds and comparing Z heights isn't going to cut it anymore. Using spheres or ellipses might be more suitable. How will you be able to stand on such objects?

Moving to pinball physics and full slopes, using 3D models is going to be a necessity - unless you feel like drawing an exponential boatload of sprites.

Kalaron said:
A port requires starting from scratch, a rewrite can keep all the content that's already there and just build on it.

After changing the collision system and physics, what content is there going to be that you can still reuse that wouldn't be reusable on another engine? If the levels need to be redone anyway...or make a converter.

Kalaron said:
A rewrite is always easier than a port.

I disagree - that's why I created Wizard. If I was trying to alter SRB2 like that, I'd probably still be working on it and getting less than stellar results.

NeoChaoTikal said:
Not that I'm anywhere close to disagreeing with you. But if there's one thing that bugs me about the software mode is the ancient unpredictable crashes that occur because that renderer was only intended to draw the simple geometry and small scope of Doom levels.

I always wanted to move to OpenGL largely for this reason. But then you open the can of worms, or, can-of-motion-blur, as you say.

Kalaron said:
I think the only way to truly make a perfect OpenGL mode is to actually use advanced OpenGL effects such as pixel shaders, fortunately, even the most basic of modern computers are becoming able to handle those kinds of things more and more each day.

Definitely...some of software's effects can only be reproduced with pixel shaders. If you want to try to duplicate software as closely as possible, you should also draw without the Z-buffer.
 
SSN, I really think you're overestimating what we want. We don't want to move to "pinball physics and full slopes"--we just want the luxury of being able to touch up the kinds of things we already have with smooth gradients instead of ugly, annoying-to-create microstairs. And we want the security of playing without random crashes. And we want PolyObject flats and multi-character MD2s (which should both be implemented in vanilla SRB2 regardless of whether we move to pure OpenGL or not.)

I agree with you that in general, ports are better than rewrites--I learned that the hard way with endless iterations of improving Spacewalk Zone, each of which made the level only a tiny fraction less crappy. But do we really need either? What Kalaron has already done is pretty much all I ever wanted from the engine (except FOF slopes, but he's already working on that).

What is so hard to understand about the idea of switching to OpenGL-exclusive, implementing all of Kalaron's goodies, and then just leaving it there? We don't need anything ultra-fancy. It doesn't have to be a sinister, slippery slope that ends with all the devs either quitting or collapsing from heart attacks.
 
Last edited:
SSN, I really think you're overestimating what we want. We don't want to move to "pinball physics and full slopes"--we just want the luxury of being able to touch up the kinds of things we already have with smooth gradients instead of ugly, annoying-to-create microstairs. And we want the security of playing without random crashes. And we want PolyObject flats and multi-character MD2s (which should both be implemented in vanilla SRB2 regardless of whether we move to pure OpenGL or not.)

I agree with you that in general, ports are better than rewrites--I learned that the hard way with endless iterations of improving Spacewalk Zone, each of which made the level a tiny fraction less crappier. But do we really need either? What Kalaron has already done is pretty much all I ever wanted from the engine (except FOF slopes, but he's already working on that).

What is so hard to understand about the idea of switching to OpenGL-exclusive, implementing all of Kalaron's goodies, and then just leaving it there? We don't need anything ultra-fancy. It doesn't have to be a sinister, slippery slope that ends with all the devs either quitting or collapsing from heart attacks.
THIS. THIS is what I mean.
 
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.
 
Last edited:
Before I say this, please note that I am not necessarily disagreeing with you--a lot of those points are valid, particularly distance lighting. But I'm wondering how carefully you've looked at SRB2CB, because it has addressed at least one or two of those problems. SRB2CB's slopes do angle the player, and does feature passable slope physics. Also, colormaps look a lot better (even if still not quite right). And I think that Kalaron is working on the sky rendering issue.

Even if we didn't have slope physics, why is it somehow less believable for Sonic to be standing straight on a 45 degree slope than for him to be standing straight on a 45 degree slope consisting of tiny 1-or-2-fracunit wide/tall steps? Even if it doesn't look good, it shouldn't look worse.
 
Last edited:
Status
Not open for further replies.

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

Back
Top