Software vs OpenGL: The rational debate

Status
Not open for further replies.
In the case of my laptop, since it has a suck*** video card, I use Software when playing online, when lag is an issue, otherwise I use OpenGL because the entire game looks better, not to mention that all the visual Software glitches due to FOFs are fixed in OpenGL and y-shear is negated.

As Mint said, all it needs is a few more fixes. From what I heard, some of JTE's OpenGL work is going into 1.1, so that would be a few more fixes right there.

Only thing I dislike about OpenGL is the fact that colormaps and lighting effects don't always appear right. But, other than that...
 
I use OpenGL because:

1. It can run at my native resolution (1280x1024) without needing to change the video mode.

2. It can run at my native resolution without either slowing down or having absolutely terrible texture precision (try it - run Software Mode in 1280x1204 or higher and notice how as you go from the top-left to the bottom-right of the screen, the texture jitters like crazy as the camera moves. And for larger walls the artifacts are even worse).

3. Poor perspective is another issue. Anytime you look up or down in Software, all it's doing is vertically scrolling a tall rendering of a scene from a static orientation. In first-person view, if you try to look up or down at all, there is massive distortion, which makes it very easy to become disoriented. If you look too far up or down, the camera will even clip through the floor or ceiling, especially in split-screen mode. It just isn't suitable for multiplayer games. Not to mention, Software breaks apart if you try to make a visible area too large or tall. OpenGL has neither of these problems.

4. It is actually competent with semi-transparencies. Rather than using a nearest-neighbor color matching method on a 256-color palette, it has access to 16-million colors. That means that semi-transparencies and lighting effects don't have nasty banding or washed-out colors. Seriously, gray water is pathetic. If the colormap says it's blue, it should BE blue, damnit.

5. Choice of image filtering. OpenGL gives you the choice of using either nearest-neighbor or bi/trilinear for filtering of textures. Because it's OpenGL, you can also turn on Anisotropic filtering, which will make distant textures render the way they should: without graininess nor blurriness.

6. Because OpenGL is a modern API, you get extra features that can't be replicated as easily in Software. Vanilla SRB2 has the lights that you get in OpenGL (Super Sonic, Emeralds, etc.), which is a nice touch. SRB2JTE and PrettySRB2 also have shadow-casting for all Things, and there are certain distributions of SRB2JTE that will even make all Thing geometry spaz out like crazy (done purposefully, mind). I haven't seen any of that stuff done in Software.

7. It's friendlier with Fraps, as video-recording doesn't run as slowly, and under some instances the counter won't show up in Software (seems to happen for some, though it shows up for me). It also doesn't make PrintScreen mess up the colors, though I use Fraps for pictures like that anyway.

In closing, yes, OpenGL.
 
Pretty much what FoxBlitzz said, except Lights. OpenGL lighting is an awesome graphical effect that Software could absolutely never replicate right. And, even if it were to be attempted, it would be horrible, pixellated, and generally everything a light should not be. (To be fair, this falls under Blitzz's #6, but it deserves a note. :P)
 
Honestly, there are major benefits to both.

Software:
Pros -
Officially supported, all level effects work (fog comes to mind)
Glitchy only in very specific situations. Otherwise, works as intended.

Cons -
Very few visual features. Those that like filtering should look elsewhere.
256 color palette can cause some colormaps to look weird.
Generally doesn't do particularly well above 640x400
Cannot look straight up and down.

OpenGL:
Pros -
High resolution works great.
Full ability to look up and down, albeit with the Paper Mario effect.
Fancy 3D card effects.

Cons -
Colormap glitching, especially on FOFs
Displays textures and things it shouldn't be able to view, either through walls or beyond the thok barrier.

Personally, I prefer software, but I use OpenGL for multiplayer to be able to look up and down. Of course, I prefer playing SNES to modern systems, so I guess I think pixelation is sexy.
 
Then run OGL at low res.

And, for a DOUBLE proof, that OGL is now supported by at least Alam, and it can be pixelly:

Shot taken in OGL at 320x240 res and resized to 914x616 (Ed: ???) in Paint, from the latest SRB2109 SVN build as of post time.
Honestly, it looks like a old magazine shot. :-)
 
Mystic said:
Personally, I prefer software, but I use OpenGL for multiplayer to be able to look up and down. Of course, I prefer playing SNES to modern systems, so I guess I think pixelation is sexy.

"gr_filter nearest" in autoexec.cfg for great justice!
 
While moot in 1.09.4, unless we find someone willing to update and maintain the hardware renderer, it may be difficult to complete some levels in 1.1. DSZ3 already has a lot of visual problems. ACZ comes to mind too, and ERZ, while currently only having some harmless issues, might get added to that list.

As for the blah water and stuff, the new palette kind of fixes that. As for some of the other things mentioned, software is now capable of antialiasing the flat textures, and I've been playing around with a player shadow.
 
Are these visual glitches present even with JTE's OpenGL fixes added?

Or is this based on the current OpenGL renderer in 1.09.4?
 
Antialiasing. Quincunx, specifically. I majored in writing graphics shit, you know. ;) I just don't want to write TWO renderers. I really don't even have time to be writing ONE.

And no, JTE's fixes do not address what I'm talking about.
 
SSNTails said:
I just don't want to write TWO renderers. I really don't even have time to be writing ONE.

Don't blame you at all. You have better things to do than trying to maintain two renderers.

SSNTails said:
And no, JTE's fixes do not address what I'm talking about.

Oh well. Theres always a chance someone might take up fixing the hardware renderer after 1.1 is released.
 
I'll Begin said:
And for those who hate OpenGL "making random redwalls" on certain levels, it's only because there's a missing texture there. You can see it in software too.
As far as this subject goes, it's really a matter of using SRB2 Doom Builder. Vanilla DB works well for certain things, ya know? ;)

Also, on the subject of my own maps, stepping into them using OGL scares me. Even with gr_filtermode set to nearest, the vast difference in lighting turns those vast, towering waterfalls and looming trees into something that seems rather insignificant. It might justbe a personal prefrence, but.....

FoxBlitzz said:
Seriously, gray water is pathetic. If the colormap says it's blue, it should BE blue, damnit.
I'd just like to note that I set the colormap keeping in mind that the water won't be horrendously blue. If I wanted a blue colormap in software, I could very well give you blue water. I just choose not to.
 
I checked OpenGL.
First of all, it was very laggy, and no matter what I did, it was always laggy. But:
- The images were more clear
- The FOV made the game look a bit like 3D
- It had better graphics
- I never saw the lighting, but screenshots beg to differ.

If your computer can handle it, use OpenGL. Always.
 
Personally, "lol opengl vs software which is better" is becoming gradually more moot. One way or another, software is going to have total manipulation of the leet high rez garphixs, considering that SSNTails pretty much said himself that OpenGL won't be worked on much anymore. Alas...

To be honest, I am a OpenGL monger, I pretty much used OpenGL for anything SRB2. I often made things that seemed perfectly normal on OpenGL, then people complain about it not working in Software. This is the exact problem with having multiple renderers - often does something mess up in one and not mess up in another.

Either way, looking at the new things being implemented, and what doesn't work on OpenGL (awesome sector fog, for example), we're going to have to use Software to (ironically) be up to date. I'm starting to get a taste for Software.
 
By the way, why exactly is OGL unsupported kthxbai? And can't you compile the R_d3d.dll and R_glide.dll in 1.1 so we can have d3d and Glide? And hope they are supported kthxbai?
 
Status
Not open for further replies.

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

Back
Top