Horde3D

OpenGL 2.1 is out now for a long time as well as the corresponding drivers. I think it should be safe to raise Horde's minimum requirements from GL 2.0 to GL 2.1. That way we could benefit from the native sRGB support and GLSL 1.2 which brings some small but handy improvements. The Pixel Buffer Objects could also be useful. Are there any reasons against that (like weak driver support for Linux or Mac)?

Shouldn't be a problem on the Mac.

However, I would ask that you make the check a log error, rather than a hard failure. The reason behind this is that the integrated Mac cards export all the required extensions to run Horde, but don't export the full 2.1 (or even 2.0) spec.

I committed a small patch to the community SVN to make this change for GL 2.0 (error only, no failure), and the Chicago sample now runs on the Intel X3100 for Mac.

_________________
Tristam MacDonald - [swiftcoding]

Yeah, I've tested on some old ATI cards before which actually implemented all of the required extensions, but don't report GL 2.0 support for some reason. Getting rid of this failure condition made Horde work perfectly on these cards

The situation with X.Org drivers (Linux, some *BSD and Solaris) is like this:

• NVIDIA: free driver is immature; proprietary driver is on par with Windows, with OpenGL 3.0, GLSL 1.3 and every extension Horde needs;
• ATI: free driver does not support OpenGL 2.0 or GLSL [1]; proprietary driver claims to support OpenGL 3.0 for newer chips (only works on Linux, no BSD support);
• S3 has drivers for Chrome 500 that claim to support OpenGL 3.0 (seem to be Linux-only);
• Intel has free drivers that seem to support OpenGL 2.1 on latest chips (the whole thing is experimental though, and currently Linux-only);
• MESA software renderer supports OpenGL 2.1 and GLSL 1.2, but there's no EXT_texture_filter_anisotropic, EXT_texture_compression_s3tc or EXT_framebuffer_multisample.

Mac OS drivers report OpenGL version 2.0, but support GLSL 1.2 everywhere [2].

In short, using OpenGL 2.1 should not decrease Horde portability on Linux, *BSD, Solaris or Mac OS.
On the other hand, as was noted above, you can't check for OpenGL version to be 2.1 on Mac.

Docs [2] state that there is no EXT_framebuffer_multisample support on Intel X3100. Is this correct?

[1] http://www.x.org/wiki/RadeonFeature
[2] http://developer.apple.com/graphicsimag ... abilities/

Yes, and I see on further testing that shadows are broken.

_________________
Tristam MacDonald - [swiftcoding]

Thanks guys for the feedback! magv, your compatibility list is very valuable.


I could imagine that some drivers did not advertise GL 2 support since they couldn't provide fully compliant NPOT support. At least I know that this was the case for some older Radeons. But I think they are all GL 2.0 now.

The X3100 on Mac seems to be the only card which does not expose GL 2.0. Anyway, I think we should rely on GL 2.0 as base requirement since the functionality and some entry points may be slightly different from the original ARB extensions and I could imagine the driver stability is better for the core functions. However, we could add a flag to the h3dInit function which makes missing GL 2.0 support be treated as a warning, if it makes sense (if we manage to get the X3100 to render correctly).

The Mac X3100 is missing ARB_render_buffer_float - apart from that it has the entire 2.0 spec (and pretty much all of the 2.1 spec)
That would be a reasonable compromise.
What is the definition of 'render correctly'? The X3100 runs perfectly with my custom shaders, but the shaders used in the samples are not fully supported.

_________________
Tristam MacDonald - [swiftcoding]

Hmm, I think at least the standard forward shading pipeline should work since it does nothing fancy. You said the shadows are still not working, right?

Yes, but I have a more-primitive shader for shadows which works fine. So the question is whether the chicago sample is the definitive minimum spec, or if *any* shaders working is the minimum.

_________________
Tristam MacDonald - [swiftcoding]

Actually I would say Chicago is the minimum since most people will probably want to use the default higer quality shadow mapping for their projects. However, if you think it makes sense to introduce the "hit or miss" initialization flag for Mac compatibility we can do that. It is not a big deal.

Sure, but do we want to artificially limit compatibility? A number of shader-heavy commercial games run on the X3100, including Spore and Quake 4.
Ja, that would make sense.

_________________
Tristam MacDonald - [swiftcoding]