LibGDX image constraints

You know how in libGdx where texture dimensions can only be in the power of two? How can i get around or get rid of that. thanks

by enabling openGl 2.0

cfg.useGL20 = true;

It’s already enabled.

Why do you need to get rid of it? Just for convenience, or for a more functional reason?

Because I do find it inconvenient, but one can always just crop the region of the texture needed inside the program.

Convenience mostly

I see. Well I’m not sure myself how to get rid of it, so I just store my images in a bigger file (like, I store my 40x24 texture in a 64x32 image) and just crop out the 40x24 region that I need inside the program.

NOTE: I think the veteran advice is that it’s probably the best idea to store all your images in a single sprite sheet that you can select the individual images from later on. I plan to do this at the very end of my project. Just in case you aren’t already doing this, it might be best to keep this in mind :wink:

boolean useOpenGLES2 = true;
new LwjglApplication(listener, title, width, height, useOpenGLES2);

That’s what I have, anyways.

Some devices won’t support NPOT textures even if GLES20 is enabled. Also, performance tends to be better using POT textures than it will be with NPOT textures.

It’s best just to use POT textures; you can use PixmapPacker if you want to automatically pack textures into a POT size. Or you can just render your NPOT texture into the next greatest POT with [icode]isPowerOfTwo(int)[/icode] and [icode]nextPowerOfTwo(int)[/icode]. Note that doing this will mean the texture will not be managed.

You should also think about using texture atlases, as it will greatly improve performance. It’s not a good idea to “wait until the end” to implement them; as they might influence decisions about how you implement certain rendering techniques. For example; if your game needs many texture atlases, it can be better to implement a sorting or some other mechanism, so that you are reducing your batch count per frame.

In what situation would a game need many texture atlases?

What would be an example of a mechanism that would reduce the batch count per frame? (actually… what’s being referred to by “batch count per frame”?)

thanks!

batch count = “render calls”

A game with hundreds of sprites that don’t fit into a single 1024x1024 atlas might benefit from a sorting mechanism. Aside from some games needing hundreds of icons and sprite sheet animations (items, tiles, spells, etc), you also need HUD/GUI elements and fonts (different sizes, styles, etc can pile up).

In this case you need to be smart about rendering, and about texture packing. It makes more sense to pack your HUD/GUI elements into a different atlas than your game tiles; then render all of your tiles in the same batch, and all of your HUD/GUI in the same batch. Also; since things like changing projection matrices, setting blend functions, switching shaders, etc. require flushing the batch, it’s not just texture atlases to be concerned about.

Other games need to be even more careful. Unless I’m mistaken, Illarion (which uses LibGDX) dynamically packs texture atlases based on what sprites/tiles are nearby the player. This is because the scenes are extremely complex, and the characters are made up of many components of wearable items/clothing.

You can debug render calls with SpriteBatch.renderCalls (print it out after ending the batch).

^ Whoa, I didn’t notice that you posted a reply to my inquiry already. Very informative, thanks!

Secret libgdx tech:
Texture.setEnforcePotImages(false);
FileTextureData.copyToPOT = true;
Has caveats, enjoy. :slight_smile: