[Nemesis6]

http://developer.nvidia.com/object/opengl_3_driver.html

Well, that driver is supposed to add support for OpenGL 3.1. If I got this right, FS2 is using OpenGL 3.0, or am I misunderstanding something? Would upgrading to OpenGL 3.1 fix anything or allow any new features? That's really it.

Edit: Thought I posted this in the code section. Oh well.

[castor]

Isn't OGL3.0 pretty new too? I doubt FSO depends on even that yet.

[captain-custard]

isnt FSO using opengl 2.1 atm ?

[The E]

I think it was OGL 3.0 and GLSL 2.0 or something like that.

[chief1983]

Shader Model 3, which I think was in OpenGL 2.0 or 2.1.

[Zacam]

Originally introduced as an extension to OpenGL 1.4, GLSL was formally included into the OpenGL 2.0 core by the OpenGL ARB. It was the first major revision to OpenGL since the creation of OpenGL 1.0 in 1992.

OpenGL (version 1.5 and newer) provides a C-like Shader language called OpenGL Shading Language, or GLSL

Fixed Render pipeline (non-GLSL mode) is capable of using Pre-2.1 OpenGL.
GLSL mode can also use pre-2.1 GLSL, but it really is not recommended. These prior versions support earlier SM versions.

The OpenGL compiler for using GLSL should be 1.20 from the OpenGL 2.1 subset or better in order to support SM3.0.
FSO currently shows no operational difference when using OpenGL 3.x as compared to using 2.x.
However, there are changes to be made if OpenGL 3.x code was to be implemented, but those changes would not be reverse compatible.
(Please note that prior OpenGL code is capable of running on newer versions, even if the structure or command is now depreciated.)

Any OpenGL fixes from drivers that also contain newer versions of OpenGL may not actually have required those newer versions of OpenGL to be fixed.

So, in short: FSO Uses Shader Model 3.0 which requires full support for OpenGL 2.0 or higher.

[blackhole]

Upgrading to a new version of openGL does not magically make the game look better or run faster.

[Zacam]

You would be surprised. Newer versions of OpenGL rendering code may have more efficient ways of processing the same commands and functions.

Your statement is analogous to saying that Platinum spark plugs vs. generic spark plugs will have no effect in the same engine.

[The E]

Isn't that dependant on your GFX-card and its drivers?

[High Max]

.

[Zacam]

*sighs*

Look. The OpenGL API in your drivers can be (within the context of the hardware constraints) updated to take advantage of newer API functions or better processing of existing functions. These updates can be applied to existing hardware (again, pending the hardware limitations) with minimal issues.

Consider: OpenGL 3.0 and 3.1 is available for any nVidia 8xxx series card or newer. But OpenGL 3.x did not exist when these cards were made. So obviously there is little in the way of the hardware being an issue to enable full feature support. Now granted, there may be some isolated functions on more reduced cards that may prevent a _full_ compatability, but the ability is there.

Consider the GeForce FX 5xxx series cards. Original drafted for the OpenGL 1.5 spec, while they do not have _full feature_ support for all of the OpenGL 2.0 specs, they can still claim an 80% feature set capability for using OpenGL 2.0. (What they are lacking is the computational ability to support Shader Model 3.0).

So yes, in _some_ cases, performance is better achieved by changing to newer hardware. However, declaring that updating one's OpenGL without changing the hardware because it will be of no benefit is ridiculous. So yes, it can be just as easy as updating OpenGL or drivers. And given that the OpenGL is usually bundled with the drivers (except in SDK's) you can get an improvement without having to adjust or change your hardware.

Wether or not you will actually see or be able to meassure this improvement is another matter entirely. Some platforms/games will see little in ways of improvements either because they are already as optimized as they will get, or are so fuster clucked that no amount of improvements to the driver will accomplish anything.

[chief1983]

He's right, the new beta nvidia drivers are proof of that.  They're basically turning on support for many OpenGL 3.1 features that weren't previously available, via a simple driver update.

[blackhole]

Wether or not you will actually see or be able to meassure this improvement is another matter entirely.

That is the point that I was trying to make. Why upgrade to a new version if you can't tell the difference? Whether or not you can see an improvement is the only thing that matters - unless you plan on adding new features later on. I don't care if openGL 3.0 has speed optimizations or better ways of rendering things - have you SEEN the graphics rendering code?! You are perfectly correct in saying that you can get preformance increases by upgrading openGL, but my point is that with FSO, you won't. There's no way you are going to get anything more then a couple of frames improvement. That is not significant. The main point I was trying to make is that upgrading to openGL 3.0 does not magically make FSO be able to support bloom or whatnot.

[chief1983]

Maybe it won't make existing games look better, but maybe it will allow certain games to run at all that previously could not.  Think if certain cards suddenly could run the GLSL required by FSO that previously couldn't.  Wouldn't it be worth it then?  This is basically the same thing.  It allows the hardware to do more than it previously could, period.

[blackhole]

Maybe it won't make existing games look better, but maybe it will allow certain games to run at all that previously could not.  Think if certain cards suddenly could run the GLSL required by FSO that previously couldn't.  Wouldn't it be worth it then?  This is basically the same thing.  It allows the hardware to do more than it previously could, period.

But FSO only uses shader model 2.0?

I mean, you're right, there's no reason not to upgrade the driver, I'm just saying a code re-haul is pretty pointless.

[Zacam]

Because you cannot make the assumption that you WONT see an improvement. And there can be many improvements that you may NOT see. Like, if the processing of certain functions is now optimized, it lowers the GPU processing, which saves your video card a few degrees of temp.

And yes, I have seen the rendering code. Very impressive. Wether or not it will actually require as much of an overhaul as some people think is another matter for elsewhere. That some changes will need to be made is definitely not in question. Besides, bloom could already be supported, and for older than OpenGL2 as neither bloom nor HDR strictly require SM3.0. It's just better on SM3.0.

Given a choice in running FSO on drivers that support OpenGL 2.0, 3.0 or 3.1, I will have to say, I'll take OpenGL 3.1 and I hope it makes it into mainstream drivers really damn soon along with Ambient Occlusion support. Because I do happen to notice a difference by comparison to just how everything looks and how much smoother the same framerate is.

And no, FSO uses OpenGL 2.0, Shader Model 3.0. Shader Model 2.0 is usable in -no_glsl mode, mileage may vary if you choose to use the Shaders without  Shader Model 3.0.

[blackhole]

And yes, I have seen the rendering code. Very impressive. Wether or not it will actually require as much of an overhaul as some people think is another matter for elsewhere. That some changes will need to be made is definitely not in question. Besides, bloom could already be supported, and for older than OpenGL2 as neither bloom nor HDR strictly require SM3.0. It's just better on SM3.0.

Oh my god, this is not my point. Have you tried implementing HDR and bloom on the current graphics? It just doesn't work! As taylor has pointed out numerous times the graphics code needs a complete rehaul before HDR and bloom start going in, the first being for it to stop rendering everything in little chunks with its own depth sorting.

Because you cannot make the assumption that you WONT see an improvement.

Yeah, I can.

[castor]

Hmm, if the software using the API has not been modified and the hardware is the same, but you still get an improvement, wouldn't it simply mean that the older OGL implementation for the HW was crappy? (so the improvement wouldn't be due to the updated OGL spec)

[DaBrain]

@blackhole

Unless you're a genius and I'm a complete moron, I'd say HDR in a space game doesn't make much sense anyway.

As for bloom, I guess if we don't overdo it, it would be a nice improvment.

[Herra Tohtori]

@blackhole

Unless you're a genius and I'm a complete moron, I'd say HDR in a space game doesn't make much sense anyway.

Well it could be used to make it so that when brightly lit objects are visible, the side in shadow is really pitch black, whereas when you're on the shadow side (and don't see the sun directly) the dynamic range would mean you would still be able to see the dark side of the ship or whatever.

At the moment you can either set the dark side to be really dark (-no_emissive_light -ambient_factor 0) and the shadows will be realistically dark for space... in which case it's a pain in the ass to see anything in the dark side of ships. High dynamic range would simulate human eyes adapting to the general brightness of the image... which I'm certain you know.

As for bloom, I guess if we don't overdo it, it would be a nice improvment.

Bloom would make much less sense to me (except if used masterfully to simulate cockpit glass distortions and reflections) since space is empty and there's no stuff to scatter light. Atmospheric and Nebula missions would benefit from it though.


I would still prefer having shadows (cast on other and self by any object) though...