2
\$\begingroup\$

i want to program a 2D game and as i did lots of tutorials and read books about creating simple 2D games, nearly always tilesets were used for the graphics. But are tilesets really more efficient compared to loading not from one but from several pictures?

Thanks

\$\endgroup\$
5
\$\begingroup\$

Yes, they are more efficient. Depending on your specific hardware and driver, massively so.

The basic idea is that you want to minimize state changes. Changing the active texture is a state change. In many cases the GPU can only handle rendering with a single state at at time. If you think of all the dozens/hundreds/thousands of shader cores that a GPU can have, if you're rendering only one single sprite at a time you're massively under-utilizing the hardware. By using a texture atlas / sprite sheet (and batching every other piece of state you can) you will allow the GPU to work on drawing many sprites simultaneously.

For the modern gaming world, the actual draw speed is probably less important than the power consumption of your game. If you're being inefficient then the CPU/GPU have to remain in their active power-sucking states for longer, greatly reducing battery life. If you're efficient and "race to sleep" (do all of your work as fast as you possibly can so that the device can go back into its low-power state until its time to draw the next frame) then mobile users (phones, tablets, laptop PCs, etc.) will be much happier. The only two real states you have are "everything is idle and low-power" or "something is running and we're high-power." Modern devices have some intermediate states and additional complexities but you can and should ignore those details: either do everything the absolute most efficient way you can manage or make sure your game is completely idle (no polling a timer or anything; make a call to explicitly wait for the next vsync event and let the OS put your game to sleep until it happens).

There's nothing quite so "amusing" as firing up a fancy 3D game on your phone and being able to play for several hours and then trying some silly little 2D game that drains your battery in 40 minutes.

And again, even as a PC game developer, laptops and convertibles are hugely popular and battery powered so being a PC developer doesn't excuse you from being considerate about users' battery lifetime.

That said, while I deeply disagree with @wondra that the efficiency isn't important, it is good advice if these are your first game development experiments to not worry about it just yet. But keep texture atlases high on your list of things to learn how to make and use after you get all the basics down.

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ Your answer also implies that for mobile devices fixed framerate/loop is much better exactly for power consumption reasons, right? \$\endgroup\$ – wondra Sep 16 '14 at 9:24
  • \$\begingroup\$ @wondra: compared to "unlimited fps" yes, very much so. \$\endgroup\$ – Sean Middleditch Sep 16 '14 at 16:56
2
\$\begingroup\$

This is one of "truths of old days" and no longer important (that much important). While using one texture is definitely more efficient(switching texture, as every operation, introduces some overhead), on today's hardware is not that big difference and the extra performance is generally not needed.
If you have hardware capable of rendering millions textured triangles and you need few tens of sprites, do you really need any extra performance? On the other hand premature optimization, that is what really hurts every beginner game programmer efficiency - why spend a week building something that will increase your fps from 1000 to 1020?
tl;dr: Using texture atlases is a good practice and it is a bit more efficient, but there often more important things to spend your time with. If you do not like them, go ahead and ignore them in your first games.

| improve this answer | |
\$\endgroup\$
2
\$\begingroup\$

Yes, using texture atlases is more efficient than using individual images.

It largely boils down to two things:

  1. The images have to be transferred onto the GPU in order to be drawn to the screen. Sending one large image is going to generally be faster than sending a ton of small images.
  2. State changes on the GPU are expensive, and switching textures is a state change. So for a lot of little images, that's a lot of state changes. Whereas using a texture atlas will allow the GPU to not have to change states quite so much.
| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ Is point 1 really true? I always thought textures resides in GPU memory so they are sent there only once... and once is o(1) complexity one of the lowest possible not mentioning the data size is the same - you would have to send there thousands of textures... \$\endgroup\$ – wondra Sep 11 '14 at 18:30
  • \$\begingroup\$ Not only texture data, but vertices and associated vertex data need pushed to the GPU. Dependent on how much data, and how much graphics memory you have, you can indeed have to send them more than once...and using a texture atlas can make it more likely you only have to send it once. Also, computational complexity isn't generally the bottle neck, bus speed and size are generally more-so. \$\endgroup\$ – XNargaHuntress Sep 11 '14 at 18:43
  • \$\begingroup\$ Fair point, with DYNAMIC_DRAW or stream, some data would have to be pushed there each frame. \$\endgroup\$ – wondra Sep 11 '14 at 18:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.