Hi there,
I have successfully built JUCE 1.21 and demo program under WinXPSP2. But when I choose OpenGL from Demo Menu an exception is raised. (\juce\src\juce_appframework\events\juce_messagemanager.cpp line 120)
Here is my configuration:
Windows XP SP2
MS Visual Studio 2003
Platform SDK WINXPSP2
DirectX SDK October
Any idea?
Hi there - there’s already a thread about this one somewhere, I think…
hello,
just FYI im also having the same problem as mpoloton, and I had also seen the following thread about the uninitialised gl context ( http://www.adbe.org/juceforum/viewtopic.php?t=546 ) though the openGL demo still causes an exception at the point where the component is made visible.
in fact after making the change mentioned in the above thread, it causes an exception during the juce::juce_updateOpenGLWindowPos thread rather than where it used to throw an exception.
im compiling JUCE 1.21 using MS Visual C++ Express, DirectX SDK December, under WinXP Pro SP2, on an Athlon64X2 processor, and everything else in the jucedemo works brilliantly
Im going to try and find the time to test just some vanilla opengl code to see if its a non-JUCE related problem
oh, and it would be rude of me in my first post to not say thank you to jules for making one of the coolest toolkits ive seen in the past few years.
hi there, and happy new year!
Can’t see why there’d be a problem in juce_updateOpenGLWindowPos()… There’s a check to make sure the context is non-zero before the function gets called - can you give me some more details about where it’s crashing?
ok… i seem to have fixed the problem i was having
in the InternalGLContextHolder::intialise() function (around line 112 in juce_OpenGLComponent.cpp) it makes a call to setup the initial context like so:
however at this stage it seemed that the sharedContext pointer was NULL meaning it threw an exception when trying to de-reference the context attribute.
all i did was change that line to the following, and it compiles and runs perfectly :o
i now have a glorius spinning cube.
ah - I’ve already got that fix in my code, so that’s good. Thanks.
I’ve got a new version to release soon too. Might do it today if I have time…
dunno if this is related to the problem i’m having…
the opengl demo doesn’t run on my machine. blank window, no updates at all when i select the opengl demo from the demoapp on the site. i tried the same demo on a diferent machine and it worked fine.
i tried recompiling and the same problem exists.
i checked the renderContext being returned from wglCreateContext and it was something like 0x0010000. i would expect a 0 from a failed call, so it seems to create the contect okay (which means that the pixel format shouldn’t be the problem).
the machine having issues is running xp home and is a dell inspiron 8200 with an nvidia chipset…
also, it’s been this way for a while, but the blue logo on the cube isn’t texture mapped properly – the texcoords are messed up in one of the last two vertices (i’d tell you which if i could get it to show up).
hmm… i did, but i think the one i tried wasn’t very opengl intensive so i tried another one (one that gets the vendor string). the vendor string is “microsoft corporation” which means it’s doing a software implementation.
i had sort of thought this was the case cuz i removed the doublebuffer call and then i got some graphics, only i could literall watch them draw on screen (no acceleration). i’m a little surprised the software opengl doesn’t work with double buffering… anyway, it seems to be an issue on my end, but i would expect juce to still work only really, really slowly…
okay, fixed the problem on my end. dell quit updating the graphics drivers for my machine a few years ago and somehow i got a generic microsoft driver installed. had to install a hacked version of the latest nvidia driver to get me even close to up to date with their drivers.
anyway, it does make me wonder how juce handles machine without hardware accelerated opengl. it seemed to simply fail to do anything instead of allowing the software implementation to kick in. probably a minor difference in how the two variations are set up initially – perhaps relating to write buffer selection (since disabling double buffering gets results on a non-accelerated system).
oh, and i think it’s the 3rd vertex that’s wrong on the blue side of the cube.
I’m not really much of an opengl expert, but would expect it to either fail or to use the software implementation. Maybe something in the pixel format descriptor is telling it not to?
well, it was a driver issue on my end. but the pixel format descriptor can force software implementation (or at least partial software). it’s probably worth some sanity checking in the context creation portion to verify that an opengl context was created, but that wasn’t a problem here.
either way, i would expect juce to produce the same results under a software implementation as with an accelerated implementation, only much slower. this is how it worked in singlebuffer mode, so i would think doublebuffer would do the same. instead, i get a non-updating area - as tho swapbuffers is failing (tho i checked and it’s not).