I'm using thinking of using an entity system in my game. So far I've been using Artemis with success. However, I have a question about texture switching. I read that switching textures too often is bad. So I load all the textures when the game loads like so:

import org.newdawn.slick.opengl.TextureLoader;
public HashMap<String, Texture> Textures;

Then for each texture I do this:

Texture tex = TextureLoader.getTexture("PNG", this.getClass().getResourceAsStream(texturePath));
Textures.put(textureName, tex);

Then when drawing entities I do this:

drawEntity() {
    glBindTexture(GL_TEXTURE_2D, Textures.get(entityTexture).getTextureID());

Say I have 50 entities, using 10 different 3D models, each with their own texture. When the drawEntity system runs, it doesn't group by which entities use which texture. So I could be switching textures before drawing each entity! Is there a more efficient way to switch textures between entities? Or is glBindTexture() a good option?


1 Answer 1


glBindTexture is the only option for changing textures in OpenGL, but there are a few things you can do to make things easier on yourself.

First of all you can wrap it with your own version. That just takes a texture number, compares it to the current texture (which you'll declare as a variable), and if it's changed calls glBindTexture and stores the texture number back to the current texture.

The simplest implementation (C, not Java, but you should be able to figure it out) might look something like this:

int currenttexture = -1;

void GL_BindTexture (int texnum)
    if (texnum != currenttexture)
        glBindTexture (GL_TEXTURE_2D, texnum);
        currenttexture = texnum;

Things get a little more complex when you get into multitexturing and texture targets other than GL_TEXTURE_2D, but that's the basic principle.

Another, more advanced, variation might involve using a texture array, but I don't think you're ready for that yet - let's get the basics right first. ;)

You mention that you're not sorting your entities so that's always a good idea. Any decent sort algorithm is good enough for most cases, and sort them by the texture they use. That will definitely get texture changes down.

Finally, the overhead might not be as high as you think. Yes, too many texture changes is inefficient, but how many is too many? It's certainly a lot higher than your hypothetical 50 - dear old Quake did more than 50 texture changes per frame back in 1996 and didn't suffer too much from it. I think you'll do OK.

So the moral of the story is that any scheme to reduce texture changes is going to add a certain level of extra complexity to your program, and that extra complexity may not be a worthwhile tradeoff. If you're already running fast enough then you're already running fast enough, and the point at which these things become a bottleneck is a lot higher than you think. Profile first, determine if it actually is a problem, then optimize; not the other way around.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .