detecting supported opengl extensions

[almos]

The extension checks in src/graphics.cpp:170-204 use compile-time checks for capability check during initialization. No wonder they don't detect anything at all (those symbols are always defined!). See

http://www.opengl.org/resources/features/OGLextensions/

for proper runtime extension availability check (point 5).

[NaN]

http://glew.sourceforge.net/basic.html

[almos]

You do:
if (!GL_ARB_texture_float)
{
//float textures not available
}

in GL/glew.h:4423 there is this:
#ifndef GL_ARB_texture_float
#define GL_ARB_texture_float 1

This is decided at compile time.

A runtime check looks like this (copied from the doc you linked, my link was the 2nd hit of google for "opengl detect extension"):
if (glewGetExtension("GL_ARB_fragment_program"))
{
/* Looks like ARB_fragment_program is supported. */
}

[thelusiv]

almos, would you like to put together a patch to address this issue? I'm sure it would be considered.

If you do, please base it on the development version: http://wiki.vdrift.net/Getting_the_development_version

[almos]

Now that I checked the GLEW docs, I see that it is very easy to fix: the lines that say "if (!GL_extension_name)" should be changed to "if (!GLEW_extension_name)". Half of them are OK, the last 3 needs to be changed.

With this change vdrift says INFO: Your video card doesn't support floating point textures. Disabling shaders.
instead of crashing on FBO initialization, if one uses Mesa.

BTW are float textures and half float pixel really necessary for this game? It runs OK without shaders, so I assume the textures are not float initially, and all shaders seem to compile fine, if this check is omitted. I tried to change "format=RGBA16" to "format=RGBA8" in render.conf.deferred (the only place it is used), and it didn't issue an error (but the mesa shader compiler hit a hardware limitation on my ati rv350...)

AFAIK these extensions are only required by GL3.x, and AFAIK Mesa won't support them in the near future due to patent issues. I can't believe HDR and the other effects can't be implemented in GL2.1.

Also, your shader codes use texture2DLod() function without checking for GL_ARB_shader_texture_lod extension.

[NaN]

I've fixed the checks. The graphics implementation is Joe's baby. I hope he can comment on the other stuff.

With this change vdrift says INFO: Your video card doesn't support floating point textures. Disabling shaders.
instead of crashing on FBO initialization, if one uses Mesa.

Mesa supports frame buffer objects(this is where most cards will bail out I think) but not floating point textures?

Edit: Feel free to post a patch if you hit bugs.

[almos]

Mesa supports frame buffer objects(this is where most cards will bail out I think) but not floating point textures?

In reply to my bugreport they wrote that:

The game uses GL_RGBA16F, which is a texture format from the extension GL_ARB_texture_float, that is not supported by Mesa.

Now I asked on IRC, and they don't support GL_ARB_texture_float on r600g either, so it's safe to assume that it's a global issue in Mesa.

BTW I was told that r3xx and r4xx cards bail out primarily because they cannot support dFdx/dFdy/fwidth calls.

I saw your committed fix. You didn't add the GL_ARB_shader_texture_lod check, which is not advertized by Mesa, and I was told that r3xx/r4xx cannot support it.

[joevenzon]

BTW are float textures and half float pixel really necessary for this game? It runs OK without shaders, so I assume the textures are not float initially, and all shaders seem to compile fine, if this check is omitted. I tried to change "format=RGBA16" to "format=RGBA8" in render.conf.deferred (the only place it is used), and it didn't issue an error (but the mesa shader compiler hit a hardware limitation on my ati rv350...)

With shaders are turned on, a 16-bit floating point render target is used for the HDR light accumulation buffer while doing deferred rendering. With shaders turned off, the fixed function pipeline is used and there are no rendering targets except the framebuffer (the render.conf file only applies to the shader path).

AFAIK these extensions are only required by GL3.x, and AFAIK Mesa won't support them in the near future due to patent issues.

Extensions are by definition extensions to the specification. For example, any card that fully supports OpenGL 3.x supports 16-bit floating point render targets because they are required in the specification. My Geforce 7900 only supports OpenGL 2.1 but also support a number of extensions such as GL_ARB_texture_float. Extensions that get promoted to core features get the ARB or EXT removed.

I can't believe HDR and the other effects can't be implemented in GL2.1.

To keep the rendering code easy to maintain, there are essentially two rendering paths: shaders off and shaders on. With shaders off, the features required are so low that even very old cards that only support GL1 can run the game. With shaders on, there's a base level of features that need to be supported. They all work fine on my Geforce 7900GT, which is GL2.1 and 5 years old. While it may be possible to add a bunch of fallbacks where the rendering pipeline gets changed around and scaled back depending on the card's feature set, that would be a fair amount of work and very difficult to test given the huge number of different types of cards out there. In fact, it's already tough enough just making sure that the "shaders on" path has all of the correct checks so that someone with a card that supports an unusual combination of extensions doesn't get past the checks and crash -- as you have noticed!