[PATCH] Build errors with OS X 10.5 SDK

[historic_bruno]

Got OpenGL-related errors while building the Alpha 12 bundles. It's similar to the problem we had before Alpha 11, with some constants not defined on the OS X 10.5 SDK.

A possible fix is attached, the only thing I really had to modify was GL_DEPTH_STENCIL_ATTACHMENT which doesn't seem to have an equivalent in ​GL_EXT_framebuffer_object. So instead I broke those particular calls into two separate ones using GL_DEPTH_ATTACHMENT_EXT and GL_STENCIL_ATTACHMENT_EXT. It would be nice to confirm that is valid and equivalent behavior before applying this patch :)

[historic_bruno]

suggested fix

[myconid]

There I go again. Yes, apply the patch.

[myconid]

Sorry, missed an obvious mistake in the patch: GL_DEPTH_STENCIL_ATTACHMENT should become GL_DEPTH_STENCIL_ATTACHMENT_EXT, not GL_DEPTH_ATTACHMENT_EXT & GL_STENCIL_ATTACHMENT_EXT.

[historic_bruno]

GL_DEPTH_STENCIL_ATTACHMENT_EXT doesn't exist in the SDK (I'm not sure it's documented to exist at all), that was why I tried another approach.

[historic_bruno]

This document looks relevant: ​http://www.opengl.org/registry/specs/EXT/packed_depth_stencil.txt

Search for "usage examples", their suggestion actually looks like the change I made, but there may be some crucial difference.

[myconid]

Yeah, an alternative to the packed GL_DEPTH_STENCIL_ATTACHMENT type is to use two separate attachments for depth and stencil (slower/uglier).

The thing is, even if your hardware doesn't support GL_DEPTH_STENCIL_ATTACHMENT (unlikely), you should still be able to compile it if the definition exists (which doesn't seem to be the case...). It's likely that you're using outdated header files.

For now, we could get away with something evil like

#define GL_DEPTH_STENCIL_ATTACHMENT 0x821A

just so you can compile for release (NB: as long as postproc is turned off in the config, most people won't use this code at all).

[myconid]

Hm, some of the examples do what you did. Maybe that's how it's done in GL4 or something. The question is, does it work for you?

(Scratch that, it doesn't work for me, so it must be GL4)

[historic_bruno]

I can't properly test it, since I only have a VM with crummy software renderer :( That was why I specifically asked k776 to test the 32-bit bundle (patch was only applied to the 32-bit 10.5-compatible bundle) on a real Mac and I'm glad he did ;)

Admittedly, it's unlikely someone needs to use the 10.5 bundle, even less likely that if they do, they have good enough hardware to use the postproc stuff, but rather than making that decision now, it would be nice to just patch it up one way or another.

We could also release A12 without the 10.5 bundle if no solution is forthcoming, it would surely only be needed by a very small fraction of our users.

Could it be a driver bug?

[myconid]

I guess we could call it a driver bug. Tbh, it sounds more like a decision by Apple to leave features out...

Anyway, I got the impression that k776 can compile from SVN in #1770. Does he have this constant available, then?

Regardless, it's probably safe to hardcode the constant for the 10.5 bundle only, so you can get it to compile. If they can't use the postproc, it doesn't matter too much.

[historic_bruno]

To clarify, I build two OS X bundles. One is 64-bit only and compatible with 10.6 or newer. It has no build errors currently. The other is 32-bit and compatible with 10.5 or newer. It requires building against the older 10.5 SDK, which has the build errors. I believe k776 uses Lion (10.7) so would have no problems with SVN.

It sounds like hardcoding the constant might be best, am I correct in assuming it will result in a GL error, in case someone happens to try it on a 10.5 system that supports GLSL and has postproc enabled (if such a system exists)?

[myconid]

I bet it'll work just fine, actually. In the worst case, they'll get GL errors and visual corruption. As long as postproc is disabled, the game will work as normal.

[historic_bruno]

Also for what it's worth, the patch works fine on my Windows system, but I guess some vendors opted not to support setting depth and stencil to the same texture separately or never tested properly, bummer :/ I'll hardcode the constant then.

[ben]

In 12998:

Fixes some build errors from the OS X 10.5 SDK, refs #1768

[historic_bruno]

Replying to myconid:

Hm, some of the examples do what you did. Maybe that's how it's done in GL4 or something. The question is, does it work for you?

(Scratch that, it doesn't work for me, so it must be GL4)

To confirm, you're saying that replacing the GL_DEPTH_STENCIL_ATTACHMENT lines with two separate calls using GL_DEPTH_ATTACHMENT_EXT and GL_STENCIL_ATTACHMENT_EXT (as in my patch) doesn't work on your system? That's really strange, since we now know #1770 had nothing to do with my patch.

[myconid]

That causes a segfault. One thing I've noticed, if I only use GL_DEPTH_ATTACHMENT in place of GL_DEPTH_STENCIL_ATTACHMENT everything looks fine. Perhaps it also binds the packed stencil buffer automatically, or perhaps it doesn't and I just can't tell :P (it's used for efficiency reasons mainly).

[historic_bruno]

I'm happy with leaving that as a patch for OS X 10.5, we already have to patch its system OpenAL anyway. I think it's not worth adding yucky compiler macros just for this, when it helps nobody.