I'm currently writing a 2d tile scroller for a hobby project and I can't find any resources to give me a clear answer to which is more efficient to do.

Each block contains tiles 44 by 24, 32px x 32px in size, and I'm rendering all immediately-adjacent blocks offscreen. With each block, I am specifying what the types of the tiles are, such as Sand, Grass, Pavement, etc. My end goal is to have dozens of unique tiles in each set, potentially having several "Grass" sets to pull from, to have a diverse set of landscapes.

What I want to do:
I would like to only load tilesets that have tiles that appear in the loaded blocks. I would do this by marking tile "families" in Tiled, as well as giving them an ID that pertains to that tileset specifically.

However, I don't know if it's just better to load all of the tiles from one large tileset on the game's start and just keep it in memory, instead of making frequent content loads

Will the game potentially run more efficiently dynamically loading tilesets based on need, or one very large tileset when the game first starts?


1 Answer 1


Is memory efficiency really a problem? 2D textures are not typically huge enough to cause issues. Splitting the tilesets into too many textures may even cause problems in itself, since switching textures is not always cheap on the GPU. You should probably just optimize for your development efficiency at this stage.

Unless you're intending to have loading screens, dynamic loading of a texture may result in a glitch. Typically you're not able to load content in the background, so loading a texture is a blocking operation. In some cases, the block may be long: for example, my HDD shuts itself down after some idle time and takes seconds to start up.

Additionally, ContentManager does not unload assets unless Unload() is called (unloading everything), so if you're using a single ContentManager, memory use will creep up anyways during gameplay.

  • \$\begingroup\$ This is the right answer, in particular, because it begins by asking whether memory efficiency is really a problem. Use one big tileset and keep it in memory. Computers these days can handle that just fine. If memory truly becomes an issue, which seems unlikely, you can deal with it then by breaking up the tileset, throwing in load screens at logical junctures, etc. \$\endgroup\$ Commented Jun 26, 2016 at 19:12
  • \$\begingroup\$ Thanks! I went with something similar. I'm keeping the separate tilesets but loading them on start, so I don't run into the 2048x2048px texture limit \$\endgroup\$
    – user72824
    Commented Jun 28, 2016 at 6:17

You must log in to answer this question.