Trouble loading textures outside the init() call

OpenGL Development JOGL Development
#1

Hello,

I’m attempting to port the client for a game I’m writing from LWJGL to Jogl as it seems like Jogl is better supported and is more of a “pure” gl wrapper than LWJGL.
But I’m having trouble defining textures (and various other things… I haven’t narrowed them down yet, but they seem to involve lists) outside of the init(GLDrawable) call in GLEventListener.
Since the init call is only made once (before the GLCanvas is made visible?), and I want to provide a splash screen in opengl that let’s the user know what textures are being loaded and so, I’ve got a bit of a problem here.

I managed to get around it by turning off autoredrawing and setting the rendering thread to the current thread. That let me define textures and everything from that thread, then call display() on the canvas, and it works.

I felt this was a bit of a hack, so I asked a friend of mine who’s running linux to try it… but the game started without any textures and various missing features (like the bitmaps for the fonts), just like it did for me at first.

So now my question is… what am I doing wrong? Is there any documentation I’ve missed somewhere that explains this strange behavior?

The current alpha of the game client can be found at http://www.theintraclinic.com/wurm/.

#2

To do this properly you need to fork off a background thread which performs just the disk I/O and conversion into the appropriate data format (e.g. byte[] or ByteBuffer). Your display() method should then pick up that loaded data from the background thread, call the appropriate OpenGL commands to define the texture objects, and update the progress bar. Once all textures have been loaded the display() method should stop displaying the progress bar and start displaying the main game.

Let me know if this isn’t clear enough. For JavaOne I ported the Grand Canyon demo (http://java.sun.com/jfc/tsc/articles/jcanyon/), which does something similar, to Jogl but don’t have those ported sources posted anywhere yet.

#3

That seems very messy…

If I understand the code correctly, the only proper place to make any opengl calls is in Runnables called from the GLContext (sub)class, and the buffer swapping isn’t performed until the Runnable returns… is that right?

If it is, then I really don’t understand the reason for this. Why not just expose the SwapBuffers and/or MakeCurrent calls in GLContext?

#4

Don’t get me wrong, I really like and appreciate what you’re doing. :slight_smile:

#5

I was an active developer of GL4Java for over a year and most of the errors reported were due to incorrect OpenGL context management, such as forgetting to free() the context at the end of the display() method. This has informed many of the design decisions in Jogl, including (1) making GLCanvas and GLJPanel final, (2) not exposing GLContext in the public API, and (3) not even exposing the makeCurrent/free paradigm to the bulk of the Jogl implementation. In Jogl everything is expressed as a closure that is run with the context made current. This has simplified the implementation considerably and made it much easier to add new functionality.

I used the GLContext.swapBuffers() call manually in one GL4Java application I wrote (for a progress bar), and upon porting it to Jogl found that changing the code to avoid the manual call made it a lot less of a hack.

#6

I still think it’s strange that the only buffer swap is performed after the only legal place to execute opengl commands returns.

First of all, it’s not exactly in line with the very procedural “normal” opengl thinking.
Furthermore, if you want to use a “special” opengllistener just to load a texture, you still have to rerender the entire screen to prevent artifacts. And in the case of the progress bar, that special listener would have to keep track of a lot of state in the instance instead of just in a single linear method.

That, or fork off a thread like you suggested, just to mimic C opengl behavior. :-/

I’ll do my best to adapt, but I have to say I don’t find this very optimal at all.
Other than that, I still love Jogl. :wink: It’s exactly what Java needs.