-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Does not work on Mac #12
Comments
I can fix this soon. It's a very simple fix |
Were you using the unstable branch or master branch? This should have been fixed in the unstable code. |
Just checked the docs. Unstable does not call glfwpollevents in the main thread. I am working on a fix right now. |
Ok, I was using the stable branch because I thought that it would have the smallest chance of crashing. I guess I was wrong... I'll try though the unstable branch |
The names are correct. Unstable isn't completely ready yet (you can see the unit testing failed.) I had committed a change to move everything to one thread on unstable, however it is not the main thread. I already started working on the solution and it should be fixed soon. But if unstable works, even better!
|
For clarification, I had never tested it on Mac before. In the unstable branch, I added unit testing for graphics. This is the reason why some of them are failing. Once they pass, unstable gets merged to stable
|
I just tested the unstable branch. The same problem persists. The function must be called from the main thread. That's just how OSX works. |
Also, I saw the the glfwPollEvents function is called in the main loop for every window. It should only be called from one thread (the main one) per frame. The one call deals with all windows. If it is called from two separate threads in windows it will crash. |
Working on a solution right now.Currently multiple windows aren't supported (making 2 windowmodules will result in an error.) Later when multiple window functionality will be added, the window module will handle multiple windows by making a new thread for each one
In short, there is only ever one window module which can handle multiple windows at once
|
I just pushed a quick fix to unstable. glfwPollEvents now gets called by main thread. Try to see if it runs now. Doing so created a strange error on my machine - glfwTerminate() somewhere along the way uses a Win32 that generates ERROR_INVALID_HANDLE. I know this because suddenly GetLastError() returns ERROR_INVALID_HANDLE after calling glfwTerminate(). This was causing crashes on my Windows machine. For now, glfwTerminate() is not in the code just to get it to run - bad practice, I know. I want to see if it works on OSX first before trying to fix the strange glfwTerminate() error Also it somehow broke something completely unrelated - the MACE-Text demo. That is also going to be fixed after this issue is closed. |
Wow! GLFW has a bug! MACE kept crashing for some reason after changing the new GLFW... I created an issue in the GLFW repo (glfw/glfw#1053) |
The GetLastError() bug is referenced in glfw/glfw#1053 For now, os::clearError() is called after glfwTerminate() as a workaround to the bug
Has it been fixed?? |
Can't test it as I don't have a mac, feel free to try |
I don't have one either. |
The glfwPollEvents function must be called from the main thread. (Windows should also only be created on the main thread). Since the WIndowModule class uses a thread callback to do the per frame rendering, this function is called from a secondary thread. On Windows and Linux this is not an issue, but on OSX calling this function for another thread leads to an invalid pointer. For a full list of the threading limitations with glfw functions, go to the glfw website: http://www.glfw.org/docs/latest/group__window.html#ga5c336fddf2cbb5b92f65f10fb6043344
The text was updated successfully, but these errors were encountered: