I have the same issue as yairadix.
Looking in
/Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/OpenGL.framework/Versions/A/Headers/glext.h
glBindRenderbuffer is declared as
extern void glBindRenderbufferEXT(GLenum target, GLuint renderbuffer);It seems to be
if that helps…
(Xcode 3.2.5 Snow Leopard System)
I don’t understand… Are you guys saying you can’t build against the 10.5 SDK, or that the binaries you build don’t run on 10.5?
Because it doesn’t make any sense that the 10.5 SDK would try to use functions that aren’t actually available in 10.5!
Can’t build against the 10.5 SDK. Works fine with 10.6. (I have issues where if I set my SDK to 10.6 wrong versions of system libs are linked in which aren’t backwards compatible. iconv being the one that messes me up all the time.) http://www.cmake.org/pipermail/cmake/2010-March/036120.html
I know people set the base SDK to say something like 10.6 or 10.7 and choose the deployment target, and that works great for the System Frameworks and that’s all you use, but it doesn’t work for system dylibs
[EDIT] - And following the once bitten, twice shy rule, I now just as force of habit change the SDK to also be the lowest target deployment as well… Makes sure any function I include in /usr/include headers(which would with the proper sysroot resolve to the long form /Developer/SDKs/10.x/usr/include) actually exists!
Well I just tried exactly that, using Xcode 3.2.5, and it all compiled fine!
Weird… What about looking at the glext.h in the full /Developer/SDKs path? Does it match ours?
I’m sure you know all this, but i’ve been bitten by it… I’ve set the SDK in my project settings, but when I hold option key and click on the overview it’s actually using a different SDK!
Again, by habit, I open up the build window and see what -sysroot is defined as now!
Ah, sorry, I’d mixed up my debug/release configs…
cool. seems to work 
btw, 5 comments still refer to OpenGLComponent. sorry for nit-picking
Intel series 4 chip seems to work now!
Thanks for reminding me! I’ll do a search for that…
That’s good - anyone else still having trouble in Windows?
The only issue I had was when I tried to attach the OpenGLContext to my TopLevelWindow instead of its content component. (The widgets didn’t react on mouse events and something was odd with the title bar).
I assume it’s just not intended to be used with TopLevelWindows, so it’s maybe worth a comment or assertion to clarify that.
Actually, it could probably work, but I’ve never tried it - thanks, I’ll have a go, and will add assertions if it can’t be done.
[quote=“jules”]
That’s good - anyone else still having trouble in Windows?[/quote]
Yes, the problem rendering the title bar persist.
Same stack trace, Mac Mini, NVIDIA GeForce 9400, Windows XP Pro SP3 (32 bits).
I just tried the latest version, and when activating OpenGL rendering in the JUCE Demo, I get kinda “jumps” when stuff moves around, as if the drawing buffers are shown in the wrong order. Furthermore some flickers occur when menus are opened (the shadows of the menus flicker in the Graphics Rendering demo, as if there was a shadow once, then none). I think the 2 problems are related.
I’d say that the software rendering seems to be more fluid, I can especially feel this in the TreeView demo when using the scrollbar to scroll the tree vertically. I think the thing that is faster is just blitting stuff.
I must say that I have a pretty crappy GPU, it’s a Mobile Intel 965 Express Chipset on Win XP 32 SP2, and so it’s good to know that it actually works on it. So far, good job, must have been a massive amount of work!I just tried the latest version, and when activating OpenGL rendering in the JUCE Demo, I get kinda
A bit of a silly question perhaps… but with setComponentPaintingEnabled and in the paint calls of that component, is there any chance of using direct OpenGL calls? This way all the mousehit stuff would work, but we could use our own calls to support things like SpriteSheets? (so the component has an OpenGLTexture, bind the texture, do some drawArrays with texture co-ords, etc)
I did try it briefly and got crashes galore…(same code works fine in the main renderOpenGL callback).
Well, the renderer doesn’t expect any GL state to be changed while it’s active, so it’ll be crashing because your code has changed something unexpectedly. If you made sure that you restored everything to exactly the same state that you found it, then you might get away with it… But it’s probably better to just do your stuff in renderOpenGL().
Just a quick notice (dont know if that was reported if so i’m sorry) when i use the Toolbar component and not paint it it gets all weird in the background (looks like some artifacts from memory) setting it’s background colour to something without alpha does not help, i had to overload the class and call my paint() class to make it look normal, however when i set a ColourGradient in my paint i still get the same bad behavior.
i paint the gradient like so (bad results):
void CtrlrToolbar::paint(Graphics &g)
{
ColourGradient cg(Colour(0xffe2e2e2), 0, 0, Colour(0xffcfcfcf), 0, getHeight(), false);
g.setGradientFill(cg);
g.fillAll();
}but with the below code it’s all good (both gl and software)
void CtrlrToolbar::paint(Graphics &g)
{
g.fillAll (Colour(0xffe2e2e2));
}[attachment=1]panel_with_gl_and_gradient.png[/attachment]
[attachment=0]panel_with_software_and_gradient.png[/attachment]
Oh yeah, that’s to be expected. It can’t transparently overlay GL over non-GL components, so you’d need to make sure you attach it to an opaque component, and either fill it in your paint routine or in the renderOpenGL call.
When using the OpenGL render and running in debug mode, I find my plugin editor window takes 3 to 5 seconds to open. Is this expected? It’s seems fine in Release mode.
What did you do to get this to run in a plugin in the first place? I’ve been trying to add OpenGL rendering to a plugin, and I keep getting errors when the plugin window is closed and the UI is deleted. Since the Juce Demo shows how to set up a class that’s subclasses from OpenGLRenderer and is using a background thread for rendering, it’s a bit unclear to me how one is supposed to go about setting things up in classes that don’t need background rendering. I just included OpenGLContext as a member variable and made these calls in the constructor:
openGLContext.setComponentPaintingEnabled(true);
openGLContext.attachTo(*this);
And this call in the destructor.
openGLContext.detach();
Nonetheless, I keep landing in the debugger in the JuceNSWindow class and see the following error in the console:
***** Unknown error at /Users/greg/Code/temp/PluginWithOpenGL/Builds/MacOSX/…/…/JuceLibraryCode/modules/juce_opengl/opengl/juce_OpenGLContext.cpp : 778
JUCE Assertion failure in /Users/greg/Code/temp/PluginWithOpenGL/Builds/MacOSX/…/…/JuceLibraryCode/modules/juce_opengl/juce_opengl.cpp, line 200
I think I’ve tried every possible permutation of commenting these lines in and out and I tried using a renderer as its being done in the JuceDemo. But the only thing that seems to change is which line the Debugger fails in.
