That won’t work. The other thread can’t perform any OpenGL commands.
um, ok your right pass in GLDrawable to the threaded loader and there you go.
I fail to see how that would help…
Is it possible to have more than one GLUpdateListener going at the same time? If so, wouldn’t that solve the problem?
Nope, the DrawableHelper will call display on all the listeners before returning to invokeGL in the GLContext, where the swapBuffers() is performed.
(in other words, display() on all the listeners must return before the buffers are swapped)
Maybe I’m missing something here but in the Threaded example I only need access to the GLDrawable to load in the textures.
If this is threaded why can I load textures in a seperate thread and set an animator to start the openGl rendering and only break into my progressbar rendering as textures are being loaded?
glDrawable.getGL()?
Does that work on both linux and windows for you?
I only develop for windows initially so I don’t know about linux. After I have a windows version any code that needs porting i.e. our exe (autoudates, checks jvm version sets paths ecodes all java files, etc…) and our actually game code will be ported at that time.
So if this doesn’t work under linux that is good to know but it isn’t a very big concern for those working with this under windows which IMO is probably the vast majority of developers.
And if it doesn’t work, that’s a bug that should be dealt with and not something that you should be trying to code around.
Then what’s all this I keep hearing about the only legal place to perform opengl calls is in the invokeGL method in GLContext? ???
The only legal place to perform OpenGL calls is within the methods of your GLEventListener.
To state again: I’d suggest doing the heavyweight work in a worker thread and informing your rendering thread of its progress. Your application will be more cleanly separable this way. A similar approach is used in updating Swing progress bars.
Err, but you just implied that the rendering thread (the thread that goes into GLContext and calls all GLEventListener) is the only thread that CAN perform those calls.
Defining lists for complex meshes, rendering to textures and even defining the textures cannot be done outside that thread.
I really don’t understand why you can’t just, say, add a swapBuffers() method, even if you only allow it to be called from within an GLEventListener call.
The worker thread does the heavy lifting of bringing in the data from disk and the rendering thread only does the glTexture2D call, which is relatively lightweight.
We’ll think about exposing swapBuffers(); please feel free to file an RFE on the JOGL Issues page. Please keep the following in mind, though: if the loading isn’t separated into worker and rendering threads, you’re going to get e.g. one redraw every second or so while the textures are being loaded. While this is happening, if your application window is obscured and revealed again, you’re going to see damaged regions for a long period of time.
That’s usually not an issue in fullscreen games.
I really don’t want to make a singlethreaded game multithreaded just to work around an artificial restriction.
I’ll file the RFE now.
Resource loading is usually best done in another thread anyway. Your main game loop can remain single threaded.
The point is that the decision to make it multithreaded should be mine to make. There’s no point at all in Jogl not exposing the swapBuffers() call.
It’s really weird as it is now, as the opengl api forces you to only have one thread doing opengl commands at a time (makes sense, since opengl isn’t thread safe), but forces you to use several threads if you want to have progress information.
Can you do something like this in your rendering function?
if( resource < numResources)
{
loadResource( resource++ );
// *** GL calls to advance the progressbar ***
}
// JOGL will swap buffers here
Not exactly like that, since I’m both loading normal textures, defining dynamic textures, building lists, and (when jogl supports it) building and filling vertex buffer objects.
I was considering adding an elaborate scheme of a list of Runnables, but then realized how much of an overkill that was for a very simple task with a very simple solution. 
/me puts on zealot suit
Hey, cool, this is the first BBS I’ve ever seen that supports CTCP ACTION. =D
/me is happy now when the “old” forums are back!
;D