[pecinko]

Hi guys,

what are recommendations regarding large images 1280x720 - to pack or not to pack?

Texture packer is storing them as 2048x2048 if I understand it right? This seams as graphics memory waste IF the skin performance does not benefit from it regardless of bigger size?

Thanks.

[topfs2]

Texturepacker will also store it as ARGB, so it will take quite a bit more space also.

I'd say that big images which are background loaded no matter might aswell be stored outside the texture bundle. Obviously this is only if you don't want the big textures to be compressed (as in GPU compression algorithms).

[pecinko]

Texturepacker will also store it as ARGB, so it will take quite a bit more space also.

I'd say that big images which are background loaded no matter might aswell be stored outside the texture bundle. Obviously this is only if you don't want the big textures to be compressed (as in GPU compression algorithms).

I'm interested in best performance especially on low horsepower systems like ATV2. What do you advise? Should I want them compressed?

[topfs2]

Well for ATV2 there is no GPU compression available (yet). GPU Compression doesn't increase performance generally but limits the needed bw and space for the GPU. Using GPU compression can sometimes lead to higher performance since it may be better optimized (with regards to texture fetching and such). its hard to say and generally best to just try it out and see what works, one of the reasons one need to optimize to a specific piece of hardware in these cases.

With larger images, if you store them as BMP that ought to be very close to whats in texture packer, its uncompressed with a little header essentially. The benefit with that is that it stores it in rgb if you want to. So I'd say do some tests, it will load faster but the performance when rendering will be the same.

[spiff]

afaik we use the hw jpeg decoder on atv2, so jpeg should be snappy as well.

[topfs2]

Oh right forgot about that.

Ideally a skinner shouldn't need to think about this all to much IMO, on systems where decoding jpg is super slow we should cache decoded on disk.

[pecinko]

Thanks, in that case it seams reasonable to leave them out of Xbt.

[jmarshall]

Just to correct a detail:

TexturePacker does NOT store 1280x720 images as a 2048x2048 texture. It will store it as a 1280x720 ARGB texture in general, or (if it decides it can compress to DXTn without losing too much MSE) it will compress to 1280x720 DXTn.

The main reason for leaving large images out of the texture bundle is that they're loaded in a background thread then, which means the UI doesn't stall while it loads.

[pecinko]

Just to correct a detail:

TexturePacker does NOT store 1280x720 images as a 2048x2048 texture. It will store it as a 1280x720 ARGB texture in general, or (if it decides it can compress to DXTn without losing too much MSE) it will compress to 1280x720 DXTn.

I was assuming it does as Xbt size was much bigger that size of a RAW images folder, which I thought is because it's storing it in "power of two" size.

[topfs2]

Just to correct a detail:

TexturePacker does NOT store 1280x720 images as a 2048x2048 texture. It will store it as a 1280x720 ARGB texture in general, or (if it decides it can compress to DXTn without losing too much MSE) it will compress to 1280x720 DXTn.

The main reason for leaving large images out of the texture bundle is that they're loaded in a background thread then, which means the UI doesn't stall while it loads.

I must ask, any technical reason why it can't be background loaded from the .xbt? sounds like we ought to be able, in theory, to just open a second fp and read it out just the same as any other image?

[jmarshall]

No reason anymore (there used to be one)

[Jezz_X]

No reason anymore (there used to be one)

if I remember right the reason was so that the main window textures could be loaded and shown at once instead of opening a window then having all the images load at different times

[jmarshall]

That's the reason why some images should NOT be background loaded, yes.

That's not the reason why images in the XBT cannot be background loaded, however.

The reason was that xbox had shared mem, so the XBT loader used to dump the texture straight into memory, tack on the texture header and register the texture. This had to be done in the app thread.

This is no longer the case, so allowing some textures in XBT to be background loaded is fine - as you say, for the majority of images that we deal with in XBTs, it doesn't make sense anyway as you want 'em loaded all at once for animation timing etc.

Cheers,
Jonathan