There is a lot of confusion around what is and is not available on Mac WRT OpenGL. It wasn't clear to me which terms were OpenGL-specific or Mac-specific.
I found the following OpenGL 4.1 spec very informative and is pretty much essential reading, especially the deprecation model sections (Appendix E):
https://registry.khronos.org/OpenGL/spe ... 1.core.pdf
TLDR:
(These are all pure OpenGL spec facts, and nothing to do with Mac per se).
OpenGL 3.0 deprecated a bunch of stuff
OpenGL 3.1 removed almost all deprecated stuff
OpenGL 3.2 introduced the notion of "profile" ("core" or "compatibility")
Core profile has all deprecated stuff removed
Compatibility profile offers the removed stuff back again, under the optional GL_ARB_compatibility extension.
OpenGL Implementations must support the core profile, and may support the compatibility profile.
So an OpenGL application targeting OpenGL 3.2+ needs to choose which profile ("core" and "compatibility" are the profiles specified so far) to conform to.
MacOS offers the choice of: 2.1 legacy OpenGL (w/ lots of extensions), or 4.1 core profile OpenGL
My recommendation would be going forwards, to maximize interoperability across platforms into the future for as long as is possible, since the features of 3+ have become required in Oolite, to move Oolite to the 3.2+ core profile API. Of course, there is no guarantee that it will work on Mac, since Apple has no interest in developing or debugging OpenGL further, so for Mac, OpenGL4.1 core profile seems the end of the road. I have no idea how performant or buggy it is in fact. I found some random demo app on the net, and it runs just fine in OpenGL4.1 core profile, but it's not a terribly demanding application (just displays an OFF model). I also have no idea (haven't spent any time looking in to it) what the windows and linux situation is with core and compatibility profiles of OpenGL 3.2+
There seems to be value in moving Oolite to the 3.2+ core profile, and it has the benefit of opening the door to the possibility of working again on Mac.
I have no idea how much work it would be to move Oolite to the core profile at this point.
From the linked 4.1 OpenGL spec, Appendix E (deprecation info)
Basically, OpenGL 3.2+ core profile has moved completely to the vertex buffer objects, frame buffer objects, and "everything is done in shaders" model of modern computer graphics. Immediate mode rendering (begin/end) and the fixed function pixel pipelines (alpha, fog, etc.) are gone. So, moving to OpenGL 3.2+ involves IMHO adopting this modern approach.OpenGL 3.0 defined a set of deprecated features. OpenGL 3.1 removed most of the deprecated features and moved them into the optional GL_ARB_compatibility extension. The OpenGL 3.2 core profile removes the same features as OpenGL 3.1, while the optional compatibility profile supports all those features.
...
OpenGL 3.2 implementations are not required to support all defined profiles, but must support the core profile described below.
...
It is not possible to implement both core and compatibility profiles in a single GL context, since the core profile mandates functional restrictions not present in the compatibility profile.
...
Functions which have been removed will generate an INVALID_OPERATION error if called in the core profile or in a forward-compatible context. Functions which are partially removed (e.g. no longer accept some parameter values) will generate the errors appropriate for any other unrecognized value of that parame- ter when a removed parameter value is passed in the core profile or a forward- compatible context. Functions which are deprecated but have not yet been removed from the core profile continue to operate normally except in a forward-compatible context, where they are also removed.
...
Removed features:
...
OpenGL Shading Language versions 1.10 and 1.20. These versions of the shading language depend on many API features that have also been depre- cated.
...
Begin / End primitive specification - Begin, End, and EdgeFlag*; Color*, FogCoord*, Index*, Normal3*, SecondaryColor3*, TexCoord*, Vertex* Vertex*; and all associated state. Vertex arrays and array drawing commands must be used to draw primitives. However, VertexAttrib* and the current vertex attribute state are retained in order to provide default attribute values for disabled attribute arrays.
...
Fixed-function fragment processing
...
Unified extension string - EXTENSIONS target to GetString. <<<< Note this! --Bogatyr
...
(and much more)
