Multiples images VS large tilesets

If you are a new Irrlicht Engine user, and have a newbie-question, this is the forum for you. You may also post general programming questions here.
Post Reply
SSJ17Vegeta
Posts: 19
Joined: Thu Nov 13, 2008 9:11 am

Multiples images VS large tilesets

Post by 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
Posts: 2600
Joined: Sat Dec 18, 2010 12:53 pm

Re: Multiples images VS large tilesets

Post by 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
Posts: 16
Joined: Fri Aug 16, 2013 5:08 pm

Re: Multiples images VS large tilesets

Post by 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
Posts: 2600
Joined: Sat Dec 18, 2010 12:53 pm

Re: Multiples images VS large tilesets

Post by hendu »

Citation required.
mongoose7
Posts: 1227
Joined: Wed Apr 06, 2011 12:13 pm

Re: Multiples images VS large tilesets

Post by mongoose7 »

Someone seems to be confused between loading textures into user space and loading them on the GPU.
SSJ17Vegeta
Posts: 19
Joined: Thu Nov 13, 2008 9:11 am

Re: Multiples images VS large tilesets

Post by 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
Posts: 2600
Joined: Sat Dec 18, 2010 12:53 pm

Re: Multiples images VS large tilesets

Post by 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
Posts: 1227
Joined: Wed Apr 06, 2011 12:13 pm

Re: Multiples images VS large tilesets

Post by mongoose7 »

Isomorphix.

I don't understand why it would consume CPU as both textures would be buffered on the GPU.
luthyr
Posts: 69
Joined: Wed Dec 30, 2009 5:47 pm

Re: Multiples images VS large tilesets

Post by luthyr »

hendu wrote: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
Posts: 2600
Joined: Sat Dec 18, 2010 12:53 pm

Re: Multiples images VS large tilesets

Post by hendu »

I was thinking of a screen quad with some source data specifying which tile to use - it would beat draw2DImageBatch handily.
chronologicaldot
Competition winner
Posts: 688
Joined: Mon Sep 10, 2012 8:51 am

Re: Multiples images VS large tilesets

Post by 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
Posts: 19
Joined: Thu Nov 13, 2008 9:11 am

Re: Multiples images VS large tilesets

Post by 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
Posts: 2600
Joined: Sat Dec 18, 2010 12:53 pm

Re: Multiples images VS large tilesets

Post by 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
Posts: 19
Joined: Thu Nov 13, 2008 9:11 am

Re: Multiples images VS large tilesets

Post by 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 :oops: .

Again, thanks for the help :)
hendu
Posts: 2600
Joined: Sat Dec 18, 2010 12:53 pm

Re: Multiples images VS large tilesets

Post by 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.
Post Reply