Let's Fix OpenGL

Status
Not open for further replies.
Sort by date Sort by reaction score
F

ForgiveThisNewb

Member
Yes, I know that there's another thread about OpenGL, but it seems to be about saying how it sucks, rather than reporting bugs in it, which is what this thread is for.

These bugs occur in official windows executable and linux trunk build of version 2.0.6, so they should not be related to my computer.
Also, the windows executable was used in Wine, so results may not be exactly the same as other people who used the windows version.
Finally, I'm using an NVIDIA 9600 GT with driver version 256.25 Beta.

Bug #1: Paper Sprites
Sprites rotate differently in OpenGL Mode in such a way that we can clearly see that they're flat 2d images when looking at them from an angle. It looks quite a bit like Paper Mario, thus the title.
This is especially noticeable when dieing:

Bug #2: Water
The water looks much different in OpenGL mode. It actually looks less realistic and is harder to see through.

Bug #3: I'm only partially underwater, right?
When only a part of a sprite is underwater, the whole sprite is colored as if it is underwater, not just the part that is.
 
These issues are all well known. The OpenGL renderer is not supported by the development team, and they are not going to go out of their way just to fix these issues. If you want to and manage to fix them yourself, feel free to submit your changes and I am sure they will be accepted. Otherwise, do not point the obvious. We all know OpenGL has faults, I'm sure most if not all of us would like to see them get fixed, but it will not happen by magic.
 
ForgiveThisNewb said:
Bug #1: Paper Sprites
Sprites rotate differently in OpenGL Mode in such a way that we can clearly see that they're flat 2d images when looking at them from an angle. It looks quite a bit like Paper Mario, thus the title.
Click to expand...

This is impossible to fix. Doom is a 2D engine; it's just that those two dimensions are on a horizontal plane. Therefore, the OpenGL renderer(which is in full 3D but has to use the same resources as the 2.5D Software renderer) has to draw the sprites in this way. Some Doom source ports with OpenGL try to get around this by drawing the sprites so that the flat 2D images are shown the same way from every angle(this is called "billboarding"), but it looks just plain goofy.

ForgiveThisNewb said:
Bug #2: Water
The water looks much different in OpenGL mode. It actually looks less realistic and is harder to see through.

Bug #3: I'm only partially underwater, right?
When only a part of a sprite is underwater, the whole sprite is colored as if it is underwater, not just the part that is.
Click to expand...

These are genuine bugs that can be fixed. They are bugs in FOF translucency and colormaps, respectively.
EDIT: Ninja'd.
 
Last edited:
MechaS3K said:
This is impossible to fix. Doom is a 2D engine; it's just that those two dimensions are on a horizontal plane. Therefore, the OpenGL renderer(which is in full 3D but has to use the same resources as the 2.5D Software renderer) has to draw the sprites in this way. Some Doom source ports with OpenGL try to get around this by drawing the sprites so that the flat 2D images are shown the same way from every angle(this is called "billboarding"), but it looks just plain goofy.
Click to expand...

ptskrn040.png


Source: http://zdoom.org/wiki/Actor_flags

Yeah, it's a different source port with a different and more advanced OpenGL, but it's STILL Doom, and it shouldn't be so hastefully cast as "impossible" in SRB2.

*EDIT: I forgot to read where you said billboarding, but isn't XY-Billboarding what Software looks like anyways? It's the same thing, you're just viewing it all the way from the top/bottom, so of COURSE it looks weird.
 
Last edited:
The sprite polygons already face the camera in the X/Y coordinates, all that's left to do is factor the camera's height into the equation in order to have the sprites look "correct".
 
Maybe add more angles in a OpenGL EXE mod, like, have the 8 normal (0° cam angle), 16 diagonal (45° and -45° cam angle), 8 bottom (90° cam angle), and 8 top (-90° cam angle). As such:
camstuff.PNG
 
Metal96 said:
Maybe add more angles in a OpenGL EXE mod, like, have the 8 normal (0° cam angle), 16 diagonal (45° and -45° cam angle), 8 bottom (90° cam angle), and 8 top (-90° cam angle). As such:
camstuff.PNG
Click to expand...

Yes, great idea, let's MULTIPLY ALL THE SPRITES IN THE GAME BY FIVE FOR A RENDERER THE DEV TEAM DOES NOT EVEN SUPPORT. It took us HOW long just to do Knux's sprites again (which are supposedly not finished)? Not to mention making character wads all obsolete and probably making most of them never complete. Have you ever tried spriting before? Hell, SSNTails hand drew all of the Sonic and Tails sprites! I dunno if the sprites for Knux were hand drawn or not (some are just edits of Sonic, IIRC), and nobody is willing to multiply the workload for a renderer the dev team doesn't even care for. And that's just for characters. ALL of the OTHER sprites in the game would have to be this way too. Badniks, scenery, etc. It's so much work for something that isn't even all that important! It's just a giant waste of time.
 
Last edited:
Sprite rotation as seen in So Far, So Bad would probably be really easy to implement in OpenGL, but I'm starting to lose the point.

These are the angles SRB2's sprites are in:

walkturn1.gif
walkturn2.gif
walkturn3.gif
walkturn4.gif
walkturn5.gif


These are the angles you would need to draw from scratch, and can't be done automatically:

run15.gif
run7.gif

run13.gif
run5.gif

run11.gif
run3.gif


Repeat for the diagonally-oriented direction. That's 8 angles for the head-on and diagonal directions, and the horizontal direction can just be rotated. 8 + 8 + 1 = 17. Multiply by 8 frames, and that's 136 sprites just for the walking animation.

At this point you might as well delete the sprites and start using a 3D model instead, and SRB2 loses a bit of its soul.
 
Neo Chaotikal said:
At this point you might as well delete the sprites and start using a 3D model instead
Click to expand...

Which is, in fact, possible in OpenGL mode (or was in the 1.09.4 days) if you can assure yourself that your character's sprite prefix is not shared with anything else.
 
FSX said:
Which is, in fact, possible in OpenGL mode (or was in the 1.09.4 days) if you can assure yourself that your character's sprite prefix is not shared with anything else.
Click to expand...

But the 2D graphics are a part of SRB2's charm. The hand-drawn graphics of Sonic & Co actually look more fluid and nice than a model usually does, and just looks nicer. 3D models (especially those odd ones like the unleashed model) would clash with the blocky appearance of the rest of the game, and if you don't want THAT either, you might as well just go to the Build/Quake engine, and SRB2 certainly isn't going to engine switch anytime soon.
 
Neo Chaotikal said:
Sprite rotation as seen in So Far, So Bad would probably be really easy to implement in OpenGL, but I'm starting to lose the point.

These are the angles SRB2's sprites are in:

walkturn1.gif
walkturn2.gif
walkturn3.gif
walkturn4.gif
walkturn5.gif


These are the angles you would need to draw from scratch, and can't be done automatically:

run15.gif
run7.gif

run13.gif
run5.gif

run11.gif
run3.gif


Repeat for the diagonally-oriented direction. That's 8 angles for the head-on and diagonal directions, and the horizontal direction can just be rotated. 8 + 8 + 1 = 17. Multiply by 8 frames, and that's 136 sprites just for the walking animation.

At this point you might as well delete the sprites and start using a 3D model instead, and SRB2 loses a bit of its soul.
Click to expand...
Unfortunate that it would extend the game size more than necessary. If this IS possible though, wouldn't someone have caught on to that angle-based sprite system, and tried creating and adding compatibility for these Y-axis sprite that he made, as well as thinking of the concept "LOOPS THAT AREN'T SCRIPTED AS A SPINDASH TUNNEL" and have socced a 360° loop system? Maybe half of that would've been considered, but don't you think SOMEONE would have caught on to some of that?
 
ah an OpenGL topic... Me and some more ppl have so big problem with enabling OpenGL: It's still saying one error: LoadLibrary() FAILED : couldn't load r_opengl.dll.

I'm so annoyed with it and I need help... is there someone who knows what to do? :/

PS: I need say my graphic is compatible with OpenGL, Bat file or SRB2 Launcher isn't working... point for that.
 
*Steel* said:
ah an OpenGL topic... Me and some more ppl have so big problem with enabling OpenGL: It's still saying one error: LoadLibrary() FAILED : couldn't load r_opengl.dll.

I'm so annoyed with it and I need help... is there someone who knows what to do? :/

PS: I need say my graphic is compatible with OpenGL, Bat file or SRB2 Launcher isn't working... point for that.
Click to expand...

Well, I'm guessing, but I'm not really guessing, that the problem is that you lack r_opengl.dll

And @UltimaXtreme, you can't implement a proper loop in deh, it takes source code editing to do something like that.

This is the point where Nev3r appears randomly with a proper loop with no source code editing, thus proving me wrong. (no seriously, it's impossible)
 
Cinefast said:
Well, I'm guessing, but I'm not really guessing, that the problem is that you lack r_opengl.dll

And @UltimaXtreme, you can't implement a proper loop in deh, it takes source code editing to do something like that.

This is the point where Nev3r appears randomly with a proper loop with no source code editing, thus proving me wrong. (no seriously, it's impossible)
Click to expand...

you're guessing wrong Cinefast :/ I HAVE r_opengl.dll.
 
Status
Not open for further replies.

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

Back
Top