[Feature request] Bind many textures at once in SpriteBatch

Since introduction of programmable pipeline, it’s possible to use several textures without re-binding them, instead of binding different textures to one texture unit.

AFAIK OpenGL ES 2.0 guarantees that at least 8 texture units may be used, and even simultaneously from one GLSL program. (can’t find a good source on this, OpenGL ES spec is not explicit about it, but I guess, it needs to be checked at runtime anyway)

So that’s a lot of space to use, most games can probably free themselves from binding any textures during gameplay at all. It can also solve the dilemma of sprite rendering order when all sprites do not fit in 1 texture atlas and also are translucent.

From what I see from the code, SpriteBatch doesn’t take any advantage of multiple texture units.

So right now they can be exploited only by going lower level (doing explicit OpenGL calls and writing GLSL code), right? Or I’m missing something?

I think it can be done like this: • add another vertex attribute (texture id) to the geometry that the SpriteBatch emits • in fragment shader, use that index to choose the right texture • instead of field Texture lastTexture = null; in SpriteBatch use some data structure which keeps at most MAX_TEXTURE_IMAGE_UNITS textures and purges them based on some criteria (last used, etc); when a sprite is requested to render, check if the needed texture is in this structure and if yes, use it; otherwise do flush(); and bind&add the new texture to the structure (freeing and reusing some other texture unit if needed)

This implies that the support for fixed function pipeline is dropped (who needs it anyway), but I guess it’s also not hard to make this thing optional.

What do you think about it?

[Tom-Ski]

Fixed pipeline isn’t supported at all.

TextureRegion describes a region on a single Texture, what exactly is the issue with that?

TextureArray is supported, but is GLES3.0 only.

There are many different potential ways in which people want to render using Batch, I think the best approach may be to make moves towards a nicer base for extension so people don’t have to build them from the ground up.

As far as this specific example goes, (for now) its probably best having this as a separate Batch, and to not touch TextureRegion or Sprite, and let the Batch handle everything.

[xGnoSiSx]

This has been suggested in the past as well, years ago. The future is now I guess. But the API must be broken to support and allow loading many textures. As a sided note, texture arrays could also be used with a variable number of layers supported per device memory. They were present even in old nexus 4 phones believe it or not. But back then (and even now?) the idea was/is to support even ancient phones.

With Pixel out and with modern android APIs becoming common place in % of users, this should be a target.