I am working on a Mac, I've got FreeGlut compiled and installed, but I can't seem to get the OpenGL 3.2 context with it. However, I can get it without any problem while using GLFW.
So in GLFW, this code works perfectly fine:
glfwOpenWindowHint(GLFW_OPENGL_VERSION_MAJOR, 3);
glfwOpenWindowHint(GLFW_OPENGL_VERSION_MINOR, 2);
glfwOpenWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);
glfwOpenWindow(500, 500, 8, 8, 8, 8, 24, 8, GLFW_WINDOW)
But with FreeGlut, this code fails(on glutCreateWindow):
glutInitContextVersion (3, 2);
glutInitContextProfile(GLUT_CORE_PROFILE);
glutInitWindowSize (width, height);
glutInitWindowPosition (300, 200);
int window = glutCreateWindow (argv[0]);
The error it fails with is:
X Error of failed request: BadRequest (invalid request code or no such operation)
Major opcode of failed request: 34 (X_UngrabKey)
Serial number of failed request: 29
Current serial number in output stream: 29
I am running on MacOS X 10.8 Mountain Lion, with Intel HD4000 graphics, having installed XQuartz as my X11 server,and having compiled and installed FreeGlut 2.8 from sources.
Does anyone know what might be the issue?
In 10.8 and 10.7 GL 3.2 is available if you explicitly call for it when setting up the GL context. Apple calls this the "Core Profile" to distinguish from the "Legacy Profile" which is GL 2.1.
I ran into this issue with Wine on OSX, it does not support OpenGL 3.2. My understanding is that the X11 server (either Apple X11 or XQuartz) currently does not implement the 3.2 support, nor is there a switch to flip somewhere to enable it. It could be for compatibility concerns since 3.2 profile will break some existing GL applications
This post suggests using GLFW (or maybe Apple's GLUT.framework if there is still such a thing)
This page explains the GL stack on OSX and confirms the 2.1 issue with GLX.
Freeglut is an extended implementation of the SGI GLUT Toolkit, and ( with a few exceptions around obsolete hardware ) implements the same functions.
Unfortunately, this includes a number of features that would break in a strictly CORE/FORWARD COMPATIBLE implementation.
Typically, if you request a context WITHOUT specifying a version or profile, you will get the best that the combination of driver and GL toolkit can offer, which is normally a compatibility profile, rather than core profile.
Note that the only thing you lose through using a compatibility profile is the supposed checking for deprecated functions. All new core function should work without issue.
This problem with freeglut is not restricted to Apple, it also manifests under Linux using some Gallium drivers. It is not clear that there is any short-term intent to rectify this, so if you need to use CORE/FORWARD COMPATIBLE, you should probably switch to GLFW or SDL.
You need to include the flag. usually under the Version. It should look something like this:
glutInitContextFlag(GLUT_FOWARD_COMPATIBLE);
Related
I'm working on an app that, due to restrictions that are beyond my control, is being built as an x86_64 app using an outdated macOS SDK (in this case the macOS 10.15 SDK).
It runs fine on an Apple Silicon mac using Rosetta 2, but the app needs to get the current version of macOS, and the available APIs lie to it under these conditions, consistently reporting the version is 10.16 when really it should be macOS 11.x or 12.x.
In other circumstances where the system API lies, I've been able to get the real info using sysctl, but in this case calling sysctlbyname("kern.osproductversion", ...) still lies to my app and reports 10.16.
How can I get the true version of macOS under these circumstances?
The only solution I've found so far is to launch the sysctl command line utility as a separate process and use it to query the system version. Here's a C++ implementation using Qt:
QProcess *p = new QProcess;
p->setProgram("/usr/sbin/sysctl");
p->setArguments({"-b", "kern.osproductversion"});
p->start();
if (!p->waitForFinished(2000)) {
// handle unlikely error here
}
QByteArray systemVersion = p->readAllStandardOutput();
On the bright side, this only ever needs to be executed once as the system version presumably won't change over the course of a process's life. Nonetheless I'll leave this question open in case someone has a better solution.
I want to run OpenGL 3.0 or OpenGL ES on Macbook Pro 2015 mid(Intel Iris Pro Graphics).
When I specify glfwWindowHint below, the error occurs and stop running.
// Initialise GLFW
if( !glfwInit() ) {
fprintf( stderr, "Failed to initialize GLFW\n" );
getchar();
return -1;
}
glfwWindowHint(GLFW_SAMPLES, 4);
glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3);
glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 0);
glfwWindowHint(GLFW_OPENGL_FORWARD_COMPAT, GL_TRUE); // To make MacOS happy; should not be needed
glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);
The error is:
Failed to open GLFW window. If you have an Intel GPU, they are not 3.3 compatible. Try the 2.1 version of the tutorials.
Do you know how to run OpenGL 3.0 with glfw3?
I'd like to extend a bit on the accepted answer, and try to answer your actual question:
Do you know how to run OpenGL 3.0 with glfw3?
You can't. Because OSX simply does not implement it.
What OSX does implement is the core profile of modern OpenGL, which was invented with OpenGL 3.2. Furthermore, OSX also implements OpenGL 2.1 as legacy OpenGL to ensure compatibility with existing applications.
Since the changes of the OpenGL 3.2 core profile are not backward compatible, there were mechanisms added so that an application can request a specific GL version and profile. Legacy applications which do know nothing about that profiles, and the non-compatible changes of modern GL, will request a GL context as they always did - and will end up with at most GL 2.1 on OSX.
If you want to use modern GL on OSX, you have to explicitely request a (forward-compatible) core profile (and as per the spec, implementors are only required to implement the core profile, the compatibility profile is optional, so OSX is conformant to the GL spec). GLFW can do this for you, but:
glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3);
glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 0);
glfwWindowHint(GLFW_OPENGL_FORWARD_COMPAT, GL_TRUE); // To make MacOS happy; should not be needed
glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);
cannot possibly work in a meaningful way. You are requesting an OpenGL 3.0 core profile which does not even exist. When requesting a GL version before profiles were introduced. the profile request will just be ignored, and you will be getting some GL context of at least the requested version, or a higher one, which is compatible to the one you requested. Since OSX's legacy GL can't fullfill 3.0, and since the modern 3.2 core is incompatible to 3.0, you get no GL context at all...
You either have to request something <= 2.1, to get a legacy context, or you have to request at least 3.2 core (+forwad compatibility) to get modern OpenGL on OSX.
Might be the specific version you are targeting. Any reason not to target 3.3?
I'm running GLFW3 just fine on my MacBook Pro (late 2014, also Iris Pro) using these window hints:
glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3);
glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 3);
glfwWindowHint(GLFW_OPENGL_FORWARD_COMPAT, GL_TRUE);
glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);
I'm trying to make an OpenGL application on MacOS X Mavericks. For this I'm using Glew, FreeGLUT (adding the due search paths on project settings and adding the linker flags also), and also the MacOS OpenGL framework.
The problem is, as soon as I get to glutCreateWindow, the program crashes with the following error:
X Error of failed request: BadRequest (invalid request code or no such operation)
Major opcode of failed request: 34 (X_UngrabKey)
Serial number of failed request: 29
Current serial number in output stream: 29
As I've seen on another post this may be because of the window server, but I have installed XQuartz 2.7.7 as so many have suggested and I still can't do it.
Has anyone ever tried to use FreeGLUT in similar conditions?
I solved by modifying my code like this: glutInitContextVersion(2, 1);
The reason is X11 doesn't support OpenGL higher than 2.1 on OS X.
I've just upgraded my MacBook Pro to Mavericks (MacOS 10.9), including Xcode.
According to Apple's "OpenGL Capabilities Table", this version has support
for OpenGL 4.1, but a call to glGetString(GL_VERSION) returns "1.2" and my GLSL
3.30 shader, which begins with "#version 330" refuses to load, saying that
version is not supported.
Do I need to do something to Mavericks to enable 4.1 support?
When you request your pixel format using one of the lower-level APIs on OS X, you need to add the following to your attribute list in order to use a core profile:
CGL:
kCGLPFAOpenGLProfile, kCGLOGLPVersion_3_2_Core
NSOpenGL:
NSOpenGLPFAOpenGLProfile, NSOpenGLProfileVersion3_2Core
Now, while the particular constant is named ...3_2Core, what it actually means is request a context that removes all deprecated features and supports at least OpenGL 3.2 (a core profile, in other words). You can get a 4.1 or 3.3 context using this same constant; in all honesty, including an actual version number in the constant was probably a poor choice.
If you do not specify this when you request your pixel format, OS X will give you kCGLOGLPVersion_Legacy or NSOpenGLProfileVersionLegacy respectively. And this will limit you to OpenGL 2.1 functionality.
If you are using a higher-level framework, then you will need to consult your API reference. However, be aware that on OS X you must have a core profile context to access anything newer than OpenGL 2.1.
Use the OpenGL library GLFW the latest version is 3.0.4...
right after you initialize glfw init
if (!glfwInit())
{
printf("glfwInit() fail to initualize. \n");
glfwTerminate();
exit(-1);
}
after you initialize glfwInit() include these 4 lines of code. these four line of code will enable you to use the highest version supported by you OS. on mac its opengl 4.1
glfwWindowHint(GLFW_OPENGL_FORWARD_COMPAT, GL_TRUE);
glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);
glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3);
glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 2);
then create your window.
_Window = glfwCreateWindow(width, height, title, 0, 0);
check to make sure it was created.
if (!_Window) {
printf("Display window fail to create. \n");
glfwTerminate();
exit(-1);
}
then make it you current window using the following.
glfwMakeContextCurrent(_Window);
after you make it your cureent window all thats left to be done is to create you main loop.
while (!glfwWindowShouldClose(_Window))
{
........
glfwSwapBuffers(_Window);
glfwPollEvents();
}
make sure you includ glfwPollEvents(); in the loop this makes it possible to use the close botton to quit the window. if you having trouble compiling the library in xcode just message me on here and i will send you a copy of the library.
I struggled a long time on this, and finally succeeded on using any glsl version supported by the graphics card.
There are several main points:
Use CORE PROFILE
Set the MAJOR.MINOR to version of GL you want to use
If not the newest version of GL used, you have to enable FORWARD COMPATIBILITY.
for example, as pointed out by #kanthonye, if you are using glfw, and use gl version 3.2, these lines are needed:
glfwWindowHint(GLFW_OPENGL_FORWARD_COMPAT, GL_TRUE);
glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);
glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3);
glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 2);
http://support.apple.com/kb/HT5942
the site title is "Mac computers: OpenCL and OpenGL support in OS X Mavericks -
Learn about the OpenGL and OpenCL versions that are supported by your computer in OS X Mavericks."
If you're using LWJGL (as of version 2.90), there's a mild gotcha in the javadoc header of ContextAttribs:
... This extension is not supported on MacOS X. However, in order to enable the GL 3.2 context on MacOS X 10.7 or newer, an instance of this class must be passed to LWJGL. The only valid configuration is ContextAttribs(3, 2, CONTEXT_CORE_PROFILE_BIT_ARB), anything else will be ignored.
If you are using SDL as your high level API there are a number of things you need to do to get 4.1 support.
First of all make sure you have SDL2 2.0.1 (or later I guess). For instance using brew:
brew update
brew upgrade sdl2
Secondly, you need to specifically tell SDL to request a core profile like so
SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_CORE );
Thirdly a quirk in how a core profile is requested on the mac actually requires you to request 3.2 to get 4.1 (!). I think this has been fixed in the SDL2 repository but not been released yet.
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 3);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 2);
I am developing an app using Xcode 4.6 on an OS X 10.8 machine. The app deployment target is set to 10.6, which is what we need to support. But when I archive the app (compile, link and embed resources+frameworks) and deploy (aka copy) it to the 10.6 test machine, it crashes with a generic Segmentation fault. It works fine on 10.7.
I can't compile the project in Xcode on the older Mac because the app is built using the newer compiler (it uses ARC, implicit property synthesis, the new objective-c literal syntax, etc.). It also wouldn't type check because the base SDK is 10.8 and it references some 10.8 tokens which the compiler on the 10.6 machine doesn't know about.
Any suggestions on how to go about debugging the app?
I'm not affiliated with this company/software in any way, but Deploymate is a paid app which can scan your app for SDK usage and tell you when you are calling selectors and APIs that are unavailable on older OS versions. This can help you track down exceptions and crashes relating to API usage.
You are very likely using one or more 10.7+ APIs that crash on 10.6. With a 10.8 target SDK you allow all the calls to function that are available in that SDK. However apps are bound late so this doesn't crash when you do not actually call those functions. You need an explicit check similar to this (here for the full screen feature):
#if MAC_OS_X_VERSION_MAX_ALLOWED > MAC_OS_X_VERSION_10_6
if (runningOnLionOrLater) {
[mainWindow setCollectionBehavior: NSWindowCollectionBehaviorFullScreenPrimary];
[toggleFullscreenItem setHidden: NO];
}
#endif
One way to determine the current version is:
int macVersion;
if (Gestalt(gestaltSystemVersion, &macVersion) == noErr) {
runningOnLionOrLater = macVersion > MAC_OS_X_VERSION_10_6;
}
For debugging the problematic calls simply set the base SDK to 10.6 and XCode should mark those functions that are not available there.
While there is no real good solution to this (I've seen simply different behaviors on different macOS versions) and no way to simply simulate an older macOS version, if you have a machine to spare:
It is possible to use an external HD, partition it and install different macOS versions. They all can be bootable and it's a matter (pain) of restarting the machine for every OS version.