-
Notifications
You must be signed in to change notification settings - Fork 3
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
projectM shaders not rendering on OSX #2
Comments
I managed to borrow a macbook today and to reproduce this. It appears that OSX is only shipping a very old OpenGL and won't upgrade it as they want people to move to Metal. I'm not familiar with the OSX ecosystem, but since I'm not seeing a configure flag for Metal in projectM I'm worried our options may be severely limited here. Thoughts? |
@diimdeep could you provide the output of running |
|
Thanks for the info. I decided to dive a bit deeper into understanding OpenGL on OSX. According to this StackOverflow question I need to request an OpenGL core profile of at least 3.2 to enable GLSL 330. Presumably, I would need to do the same to use GLSL 300 shaders. But Rack is built to use GL2 and I can't control the window hints anyway since they are given at Rack startup time. I have no idea if there's a workaround this, I don't actually know how OpenGL works. |
I've done some experimenting with switching out OpenGL contexts, and it gets messy. Here's a call for help I put on the NanoVG side: memononen/nanovg#543 |
I've been able to make some encouraging progress here but hit another roadblock. On my Linux I can move all projectM rendering to another OpenGL context. To do so I had to move all projectM interactions to a separate thread. I then had to enable resource sharing between my context and Rack's main context. Of course I have to create my context as an OpenGL 3.3+ context to have sufficient GLSL support to run projectM's shaders. But on OSX, it's not that simple. I can create my OpenGL 3.3 context and render to it just fine, but only if I disable sharing. This is because the Rack context is using a compatibility profile whereas to obtain an OpenGL 3.3 context I must request a core profile. So it looks like I have a few choices:
I'm leaning towards option 3 right now. Thoughts? I could still ship the current module that displays the projectM visuals in-rack, but it wouldn't work on OSX. |
This window has basic options to fullscreen, minimize-on-close, and randomize the preset. This should solve the OSX compatibility (#2) problem and better enable workflows like displaying the visuals on a separate monitor and recording them.
This window has basic options to fullscreen, minimize-on-close, and randomize the preset. This should solve the OSX compatibility (#2) problem and better enable workflows like displaying the visuals on a separate monitor and recording them.
I've implemented option 3 after some refactoring. This is all in branch glfw-separate-context, and I have builds using this (on top of the latest master, so with the non-threaded windows build of libprojectM, shouldn't cause crashes on Windows) at https://github.com/korfuri/Milkrack/releases/tag/experimental-glfw-separate-context-4 This changes the module slugs (because there are now 2 modules), so patches will break, but it's easy enough to re-create them. A small feature note, inputs are now normalized to the left. |
I've verified that the experimental release above works on Windows, Linux and OSX (except the embedded mode on OSX, as expected). I'm going to clean this up, and unless something goes wrong, I'll release this today. |
Awesome, thanks! |
Release is out :) https://github.com/korfuri/Milkrack/releases/tag/0.6.0 |
macOS, macbook 2013
compiled fine, but this errors from terminal while running
shows a scaled down version of my Rack
The text was updated successfully, but these errors were encountered: