Multiples images VS large tilesets

[SSJ17Vegeta]

Hi,

I'm currently developing a 2D side-scrolling shoot-em-up with Irrlicht. I'm asking myself a question before going on further about my graphical assets organization.

What are the advantages (if there are, apart perhaps initial loading time) of loading large images composed of several sub-textures over separated individual files (one texture each) ?

Thanks in advance

[hendu]

Runtime performance. Switching a texture is not a free operation, so if you have everything in one big texture atlas, you never need to switch.

[Isomorphix]

There's actually no difference at all*, if you handle the textures with a memory pool.

Edit: The performance loss is next to nothing. Plus you'll be able to load specific textures- lets say half of them at a time- to reduce memory usage.

[hendu]

Citation required.

[mongoose7]

Someone seems to be confused between loading textures into user space and loading them on the GPU.

[SSJ17Vegeta]

Hi,

Thanks for your answers. I realised I haven't fully mentioned what purpose I perhaps intended to use tilesets for.

- GUI skinning (at the moment all GUI element skin parts are divided in separate files, one file named "button.png", another named "checkbox.png", etc).
- 2D "floor" tiles just like any old-fashioned JRPG, drawn in a double for loop doing draw2DImage().

So, for the moment, the purpose is fully 2D. I don't know if it changes anything mentioned in your replies.

From what I understood from hendu, the VideoDriver switches the "current" texture each time a draw2DImage() call is done with a different texture parameter, hence being CPU-consuming ? (sorry for my poor english btw).

Also, Mongoose7, whose post were you referring to ?

[hendu]

Yes, both of your cases would have the texture switch overhead if you used separate textures.

From what I understood from hendu, the VideoDriver switches the "current" texture each time a draw2DImage() call is done with a different texture parameter, hence being CPU-consuming ? (sorry for my poor english btw).

This is correct.

If you have a single texture atlas, you can later on replace your for-loop with a single draw call, for a much greater efficiency.

[mongoose7]

Isomorphix.

I don't understand why it would consume CPU as both textures would be buffered on the GPU.

[luthyr]

Yes, both of your cases would have the texture switch overhead if you used separate textures.

From what I understood from hendu, the VideoDriver switches the "current" texture each time a draw2DImage() call is done with a different texture parameter, hence being CPU-consuming ? (sorry for my poor english btw).

This is correct.

If you have a single texture atlas, you can later on replace your for-loop with a single draw call, for a much greater efficiency.

Yeah, I think there may be more to gain with using something like draw2DImageBatch to reduce draw calls.

[hendu]

I was thinking of a screen quad with some source data specifying which tile to use - it would beat draw2DImageBatch handily.

[chronologicaldot]

@SSJ17Vegeta -

The advantage of keeping files separate is that they are easier to change later on. This is nice if you decide to create temporary graphics first (or you just happen to redo something and make it better later on).

If you're using the software drivers (software driver 1 or Burnings), I don't believe there is any performance advantage for using big textures as opposed to individualized ones. But I take it you're probably using OpenGL or DirectX.

[SSJ17Vegeta]

Hi guys,
Wow, so many answers Where to begin ? draw2DImageBatch() seems a really good idea.

I thought about the quad solution actually, wondering if the gain would be significant.

Just to clarify if I'm mistaken, It would mean I should :

• set a render-texture-target by calling

  Code: Select all

  videoDriver->addRenderTargetTexture()

  and

  Code: Select all

  videoDriver->setRenderTarget()

• draw2DImage / draw2DImageBatch -> same job I'm currently doing in 2D.
• set the RTT as texture of the quad
• clear the RTT with

  Code: Select all

  videoDriver->setRenderTarget(NULL);

• render the scene

I wonder how doing those extra operations (rendering "twice") could actually be faster than just one draw2DImageBatch() (not that I'm doubting it, just wondering what makes it faster). Apart from performance, I imagine that using Irrlicht's 3D capabilities would allow me to use other neat features (shaders, animators for projectiles, particles...)

@chronologicaldot :
I agree that separate textures would be easier to maintain, but that's not a problem for the moment. My graphist friend is okay with the tileset idea
And yes, I'm using OpenGL as driver.

[hendu]

No, the quad would go something like this:

- set up a texture telling which tile is used at which part of the screen
- bind this texture, and your tileset texture
- draw the quad with a shader that picks the correct tiles based on the info in your other texture

If your tiles are 64x64, then your index texture is 1/64th the resolution of the screen in both directions, very small.

[SSJ17Vegeta]

Wow. You just blew my mind away. Soooo... that would mean the GPU would do most of the work here, right ?
Basically that would be :

• Create a software texture (IImage ?) where one color = one different tile in the tileset (Quite small indeed). That image would have to be re-generated every time my scrolling position makes a new tile appear/disappear on the edges of the screen.
• In a class inheriting IShaderConstantSetCallBack, in method OnSetConstants, I bind the two textures with something like that :

  Code: Select all

   
  s32 layer0 = 0; // Indices of textures in the node material
  s32 layer1 = 1;
  services->setPixelShaderConstant("generatedTexture", &layer0, 1);
  services->setPixelShaderConstant("tileset", &layer1, 1);
   

  and also the scrolling position to determine the offset of the textures

Now my big question is : how would you do that using GLSL shaders ? I'm a complete-utter n00b in shader programming =/ I can see how to bind them into a variable, declaring something like that :

Code: Select all

 
uniform sampler2D generatedTexture;
uniform sampler2D tileset;
 

But from then on, it's complete mystery .

Again, thanks for the help

[hendu]

Yes, the work would be mostly on the GPU.

The implementation depends on the size of your tiles, how many tiles are in each row, etc. But like I said, if you have the tileset in one texture, you can easily convert from the for loop later on; do the for loop first to get your program running.