7
\$\begingroup\$

Does it make any sense to include a large image (with dimensions of say 1920x1080) in a TextureAtlas and then use it with libgdx for example?

Or should I rather use it individually and include the .png file into the assets folder as it is?

Thank you.

\$\endgroup\$
5
  • \$\begingroup\$ See also gamedev.stackexchange.com/questions/31315/… for reference. NB: your question is not Java, Android, or libgdx specific, it's a more general policy thing. \$\endgroup\$
    – MrCranky
    Commented Jan 22, 2014 at 12:55
  • \$\begingroup\$ Thanks for the remarks, I removed the mentioned tags, as this is indeed a more general question than something related specifically to them. \$\endgroup\$
    – VictorB
    Commented Jan 22, 2014 at 13:06
  • \$\begingroup\$ I thnik it should stay tagged as android, that somehow invalidates the answers. In mobile platforms size matters more. \$\endgroup\$
    – concept3d
    Commented Jan 22, 2014 at 13:14
  • \$\begingroup\$ I think I'd agree with that @concept3d \$\endgroup\$
    – MrCranky
    Commented Jan 22, 2014 at 13:15
  • \$\begingroup\$ Agreed, tag restored. \$\endgroup\$
    – VictorB
    Commented Jan 22, 2014 at 13:21

2 Answers 2

Reset to default
3
\$\begingroup\$

Use it individually. Texture atlases are used to gain efficiency by minimising texture swaps for many small textures, and avoiding wastage due to textures having to be bumped up in size to dimensions that are a power-of-two. A single image on an atlas gains you nothing except more book-keeping, and if the atlases are required to be power-of-two in size, your example image would need to be 2048x2048. That's a lot of wasted space.

The original tags included Android, which brings some extra factors to the discussion:

A 1920 x 1080 image will most likely need to be compressed to work on Android anyway, which comes with a need for power-of-two sizing. PNG is not a native format, so any PNG images will have to be converted and probably compressed before use. So even storing and using it individually, for loading and rendering it will be bumped up to 2048x2048 before it's compressed. You could use it at its native resolution uncompressed, but it would be massive in memory, and you probably want to avoid that. In practice we've always used compression on full-screen backdrops, but left texture atlases uncompressed (because the quality drop is far more noticeable on the smaller sprites); that's a pretty common policy for most places I believe.

\$\endgroup\$
2
  • \$\begingroup\$ Thank you. My question, though more general than intended by me, is more related to a libgdx perspective in my case. This means I don't need to handle loading PNG's efficiently on my own - libgdx does that on its own. I simply need a proper way of storing it, I will end up creating a Sprite based on it anyway, just needed to know how to store it best, since it is large and I don't want to have to scale it up on full hd devices. If I am still misunderstanding anything, please do clear that up for me. Thanks again. \$\endgroup\$
    – VictorB
    Commented Jan 22, 2014 at 13:16
  • 1
    \$\begingroup\$ Definitely avoid using a texture atlas then. The compression issues we're talking about are really a side issue. A crucial side issue, for full screen texture rendering, but not related to the decision between atlases and single textures. In general only use an atlas when you have many small textures. \$\endgroup\$
    – MrCranky
    Commented Jan 22, 2014 at 13:18
3
\$\begingroup\$

First of all 1920x1080 is not power of two, even if your card support NPOT textures I think it's a best practice to use a POT texture.

Second let's calculate the size in bytes. 1920 * 1080 * 4 = 8294400 bytes that is around 8mb of memory. Since the answer is tagged as android I assume you are talking about a mobile platform. A lot of the mobile platforms can't handle more that 2048*2048Citation needed.

So if you are talking about it as a stand alone texture that's big! If it was part of an Atlas that's even worse, I assume the atlas will be much bigger.

My advise use it as stand alone. And make sure you use don't alot of memory, you might need to scale it down.

\$\endgroup\$
3
  • \$\begingroup\$ Thanks. I wish I could up your answer, just not enough reputation so far :-). As for the usage of POT as opposed to NPOT, I don't think this would be an issue, since my game is targeted for devices with an Android version of at least 3.0, and since OpenGL ES 2.0 is supported from version 2.2, and since OpenGL 2.0 doesn't enforce usage of POT images, I guess 1920x1080 should work. Am I missing anything here? \$\endgroup\$
    – VictorB
    Commented Jan 22, 2014 at 13:07
  • 1
    \$\begingroup\$ Yes, two things. First is that the texture size limit is a per-device restriction that you'd have to interrogate at run-time. Most will support more than 1024x1024, many 2048x2048, few or none will support 4096x4096. Second is that OpenGL 2.0 doesn't require it, but practicality does. Rendering and loading uncompressed, non-POT images is slow. Even if you were prepared to eat the memory cost, it's really not ideal to render a full-screen, uncompressed texture every frame. \$\endgroup\$
    – MrCranky
    Commented Jan 22, 2014 at 13:15
  • \$\begingroup\$ Mm, I'll think about the possibility of making it a POT image, but as far as I know, from a libgdx perspective, it is best to load the highest resolution image possible, and then libgdx will just scale it up or down as required. Resizing is being performed according to the device screen width and height anyway. \$\endgroup\$
    – VictorB
    Commented Jan 22, 2014 at 13:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .