OS X and OpenGL source ports

[Csonicgo]

I'm more of a Unix/Linux programmer, so when compiling source ports for OS X, I use Homebrew (it's like macports) to compile them. This was all well and good until I somehow forgot that OS X is super anal about the whole OpenGL thing.


GZdoom recently released a new version that requires OpenGL 3 to function at all, but as the code is now, it refuses to work, at least on OS X.

Given that I can't stand XCode and won't tough it with a 10ft. pole, what options do I have to make OpenGL ports work on OS X?

[Graf Zahl]

There's a native port of GZDoom for MacOSX maintained by someone else, some searching should help you find it.

Of course due to Apple's strange attitude towards the transition phase from compatibility to core profile it'll be restricted to GZDoom 1.x, unless Apple catches up with modern versions, like 4.4.

[printz]

I wonder what new surprises will YOSEMITE will bring with regards to compatibility.

[Graf Zahl]

As far as I know, they won't do any significant step forward, at least it won't feature the extension GZDoom requires.

[Csonicgo]

Is 1.x still maintained with patches from zdoom? If not, what was the last revision for 1.x?

[Gez]

http://alexey-lysiuk.github.io/gzdoom/

Looks like it's kept up to date, last sync with ZDoom codebase was, as I type this, three days ago.

The 1.x branch on the official repository (coelckers' account) isn't updated anymore, last version was the 1.8.07 release.

[Csonicgo]

the tagged release runs fine. I'll have to check out the fork, even though it requires ibtool, which requires XCode.

[Blzut3]

You do realize you can install XCode and use just the command line tools right?

[Csonicgo]

Blzut3 said:

You do realize you can install XCode and use just the command line tools right?

Unfortunately, ibtool is not included in the command line tools. The full XCode must be installed. GZDoom will still say only OpenGL 2.1 was found regardless, and refuse to run.

alexey-lysiuk's gzdoom fork breaks on compile:

Linking CXX executable ../gzdoom.app/Contents/MacOS/gzdoom
ld: warning: ignoring file /usr/local/Cellar/glew/1.11.0/lib/libGLEW.dylib, file was built for x86_64 which is not the architecture being linked (i386): /usr/local/Cellar/glew/1.11.0/lib/libGLEW.dylib
Undefined symbols for architecture i386:
*garbage*

GLEW works for the "official" 1.8.07 version of the code. Why it doesn't for alexey's version, I have no idea. I've tried to force -DCMAKE_OSX_ ARCHITECTURES to "x86_64" and blank, to no success. My GLEW is the Homebrew version.

[Graf Zahl]

Gez said:

http://alexey-lysiuk.github.io/gzdoom/

Looks like it's kept up to date, last sync with ZDoom codebase was, as I type this, three days ago.

The 1.x branch on the official repository (coelckers' account) isn't updated anymore, last version was the 1.8.07 release.

Which doesn't mean of course, that I can't merge the ZDoom changes for an 1.8.08 release, if some need arises.

[Csonicgo]

Graf Zahl said:

Which doesn't mean of course, that I can't merge the ZDoom changes for an 1.8.08 release, if some need arises.

That would be beneficial for my Windows box too, as the new GZDoom hangs upon loading a map, causing my graphics driver to return a "Too many errors" screen and a force close of GZDoom. Given that my card supports OpenGL 4.4, this is quite odd.

[Graf Zahl]

That's indeed odd. What kind of system are you using? And how does such an error screen look like?

[Csonicgo]

Graf Zahl said:

That's indeed odd. What kind of system are you using? And how does such an error screen look like?

Like a fancy Windows XP error screen. I haven't gotten them after I updated my drivers - Lenovo's "certified" drivers were a year behind. I got the betas and they work perfectly.

[Graf Zahl]

Csonicgo said:

Lenovo's "certified" drivers were a year behind.

OEM drivers are the root of all evil when it comes to system stability...