By this, I really mean the OpenGL standard as embodied in the specifications; they have made it impossible to implement a single OpenGL path that works with Legacy, GLES 2.0, and OpenGL 3.3. In particular:
VAO objects are not supported in GLES 2.0 but are required (and required not to be the default) on OpenGL 3.3; see https://github.com/sensics/OSVR-RenderManager/issues/231
Compatibility profiles are not available at all on the mac, and are only available back to OpenGL 3.0 on Mesa, but modern codes want OpenGL 3.3; https://github.com/sensics/OSVR-RenderManager/issues/68
The first issue requires a code change (same code won't compile) to support both GLES 2.0 and newer versions. This can be hacked in to work differently on different platforms for now but we'd like a more robust fix.
The second requires a way to specify which profile is desired for OpenGL at client run time. It can be handled immediately using the Toolkit approach to define the OpenGL functions, or by opening the profile ahead of time in and opening of SDL, which will then share the context. We probably want a way to specify it going forwards: this involves both Core/Legacy/Compatibility and version number. Maybe extend the name passed in from "opengl" to a set of annotated ones.
By this, I really mean the OpenGL standard as embodied in the specifications; they have made it impossible to implement a single OpenGL path that works with Legacy, GLES 2.0, and OpenGL 3.3. In particular: VAO objects are not supported in GLES 2.0 but are required (and required not to be the default) on OpenGL 3.3; see https://github.com/sensics/OSVR-RenderManager/issues/231 Compatibility profiles are not available at all on the mac, and are only available back to OpenGL 3.0 on Mesa, but modern codes want OpenGL 3.3; https://github.com/sensics/OSVR-RenderManager/issues/68 The first issue requires a code change (same code won't compile) to support both GLES 2.0 and newer versions. This can be hacked in to work differently on different platforms for now but we'd like a more robust fix. The second requires a way to specify which profile is desired for OpenGL at client run time. It can be handled immediately using the Toolkit approach to define the OpenGL functions, or by opening the profile ahead of time in and opening of SDL, which will then share the context. We probably want a way to specify it going forwards: this involves both Core/Legacy/Compatibility and version number. Maybe extend the name passed in from "opengl" to a set of annotated ones.