loading textures in jogl

OpenGL Development JOGL Development
#1

I’m really fighting with this, and there’s gotta be a better way. I’m a complete newb and am probably just being stupid :slight_smile:

My game can run in several distinct modes, and it’s possible the user can play an entire game and only ever enter one mode. So classes for modes are only loaded as needed. This is causing a problem with texture loading.

As I understand it textures should only really be loaded in init(), but loading them in display() should work too since I’ve got the GL thread’s full attention. Obviously loading textures in display() is not ideal, but it’s also not bad because the first calls to display() are usually trivial things like displaying menus and such. By the time the game is really running everything is loaded and fine.

So what I’ve done is in init() I’ve requested 100 textures from glGenTextures(). Then I keep track of which ones of those I’ve handed out.

Whenever someone needs a texture loaded, they give their InputStream and the tga is loaded from disk into a TGAImage object, a texture name (int) is assigned to it, and all of this is shoved into a simple Texture object which goes into a java.util.List.

If on display() the renderer notices the list isn’t empty, it goes and loads those textures. This is already getting ugly, but it gets worst when the two threads go after that list at the same time, getting concurrent modification exceptions. The thought of synchronizing the whole process is not appealing, so I’m thinking there’s gotta be a better way. Restructuring my game to load everything at the beginning would be a ton of work.

#2

Okay I have to ask, why are you loading textures in a seperate thread than your rendering thread?

Also a couple of issues that you might want to consider from an architectural perspective. You’re storing the textures you’ve loaded in a List. We if you need to store them at all you’re probably going to want to get to them again at which time you’ll be doing a linear search through the list to find a texture. Meanwhile you already have a key for the texture (the int that game back when you created the texture) and it is perfectly suited to being coaxed into being the key for a HashMap or similar allowing direct lookups when you need to get to those textures again.

In any event you will need to synchronize access to the list or use a synchronized data structure to stop two threads from modifying the list while its being accessed. You can solve this by using a Vector for the datastructure (it is synchronized) or synchronizing your access methods (a better move, but if you’re a true newbie - just use the Vector).

#3

I’m not loading the textures in a seperate thread, I’m queuing them up to be loaded the next time my rendering thread gets a chance. Since init() is only called once at the beginning and most of my textures won’t be loaded till well after that, I need some kind of system to get them in there. By asking GL for a bunch of texture ids ahead of time, I can go ahead and prepare everything before hand.

The list is just textures that need to be loaded (loaded as in glTexImage2D() not loaded up from the filesystem, they’re sitting around in TGAImage objects at that point). I have a simple Texture class that’s like

class Texture
{
int index;
TGAImage tga;
…
}

Once the Textures from this list are loaded into GL then that list is emptied. I don’t think I need to get the texture again once GL has it. Everyone who needs to know about a given texture has its int key.

I’ve gone ahead and synchronized everything. And it is working, I’m just not convinced it’s the best way to do it.

#4

Sounds reasonable.

Be careful about the synchronization of ‘everything’ though. Just synchronize access to the List datastructure. Since you’re not a heavily multithreaded application the chances of seeing lots of monitor locking issues isn’t high, but just for good practice - synchronize only what needs synchronization.