Oolite Bulletins

So the key sticking point in bringing back the Mac build of Oolite is the move to using OpenGL 3+, and Apple's support of those versions of OpenGL.

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)

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)

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.

Bogatyr wrote: ↑Sun Sep 22, 2024 5:22 am

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.

This right here is the tldr. From my point of view doing all this on Oolite is effectively rewriting the engine from scratch. Feasible? Possibly but there is so much old fixed function pipeline code in there - it's a 20-year old project after all, that I don't think it will be achievable from a practical standpoint. Hope to be proven wrong one day.

another_commander wrote: ↑Sun Sep 22, 2024 7:37 am

Bogatyr wrote: ↑Sun Sep 22, 2024 5:22 am

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.

This right here is the tldr. From my point of view doing all this on Oolite is effectively rewriting the engine from scratch. Feasible? Possibly but there is so much old fixed function pipeline code in there - it's a 20-year old project after all, that I don't think it will be achievable from a practical standpoint. Hope to be proven wrong one day.

Right. My point, perhaps implicit, was also that by moving to 3.2 and choosing (by default) the "compatibility profile," which is optional for conforming implementations, that that also basically places a future limit on Oolite.

At least now we know that "trying to tweak Oolite to get to 4.1" [core profile] is not possible, as the old functionality is actually gone.
Everyone feel free to confirm my findings in case I've read things incorrectly.

I found an issue on Github. Is it still up to date? Or maybe connected to this thread?
https://github.com/OoliteProject/oolite/issues/156

hiran wrote: ↑Sun Sep 22, 2024 8:23 pm

I found an issue on Github. Is it still up to date? Or maybe connected to this thread?
https://github.com/OoliteProject/oolite/issues/156

It's not relevant anymore. We are on OpenGL 3.3 now and the -noshaders startup option now works. Let me close that one real quick.