Nice overview of the topic! Your game looks interesting as well, congratulations on getting most of the way through development, and good luck with finishing it off! :)

If you'd like some more exposure for this (or other articles) you might also consider publishing it as an article here on GDNet. Once approved articles are rotated through display on the front page, shared via social media, and of course added to our archives. You're welcome to link back to the original source, and can also provide links to your game in the author bio at the bottom! :)

I really enjoyed your article, through and through, but there was a little thing that bugged me:

• Tiles save clock cycles! It is a huge benefit to the GPU to render one tiny image many times instead of rendering one monster background image.

How is it a benefit to draw a tiny image many times (lots of draw calls) over rendering a single rectangle in one draw call, with a big baked texture of the tilemap? Even if the tiles come in one batch of geometry, and are rendered in a single draw call, how will that be faster than just rendering two triangles for the monster background approach? After all, filling the screen with pixels of this tilemap would take about the same time with both approaches right? (fill-rate wise), Or am I missing something?

As far as I know, when you draw geometry that falls way outside the viewport, the extra cost for this is relatively constant. This should mean that it doesn't matter too much if you overflow the viewport size by 1000 or 10000, the rasterizer will be smart about it.

As you can see in many games, they use tons of huge images that mostly take all or big parts of the screen, and the framerate is not affected by that. Water planes are usually huge and can cover all the screen and way beyond. Skyboxes are always covering the whole screen. Post processing steps render full screen buffers potentially dozens of times to apply many effects. Terrain usually covers lots of the screen.

The texel fetch step may or may not be slower for bigger images, but this shouldn't be the reason of your slowdowns if you re not doing something fancy and the picked texture sizes are adequate.

From my experience, using a vertex buffer with all the tiles and rendering it in one draw call with a single spritesheet active, that is the most efficient approach, because its very flexible, pretty fast, and uses no extra texture memory. If you pre render tiles into big chunks, you use tons of texture memory, have a bit faster rendering time, but you can't animate or change tiles as quickly.

So yeah, I don't think you're doing it wrong !

"The seasoned programmer may have also noticed that we changed the Tile from a class to a struct. This is a very important change, because we no longer need a memory reference to the Tile, since it's stored on the Stack memory segment. That's another 4 bytes of savings, or 500 MB total. "

Since we are on it, I'd also like to question you about that paragraph. You said that changing from a class to a struct makes a difference in the size of the data, I don't find this to be true, as a c++ programmer, but I am not absolutely sure you are using something else than c++, right?

edit:posted in wrong thread

Tiles save clock cycles! It is a huge benefit to the GPU to render one tiny image many times instead of rendering one monster background image.

In general, this won't be true when it comes strictly to rendering performance. The pixel shader will be run the exact same number of times in either case (there would be a possible difference in texture fetch speed due to the texture cache, but I wouldn't expect this to favor the tile-based approach). Rendering lots of tiles also means you have more geometry to process. This would be a relatively minor cost though. I would expect the "one monster background image" to have a minor/insignificant performance benefit - when it comes strictly to rendering.

When it comes to memory usage though, obviously it's going to take a lot more memory. And thus a lot more time to load into the GPU when it's loaded. So "one monster background image" would have a negative performance impact when new sections of map are loaded.

There is one immediate benefit that I can think of; that is that if you use a large image, parts of it will usually be outside of the viewport out of view, but the GPU will still have to do work on it. In this way, tiles help out on CPU cycles, I suppose I could re-word this part.

The only work the GPU will need to do is for the vertex shader, which would be irrelevant in this case. There's no cost for "rendering" pixels that are outside the viewport.

The seasoned programmer may have also noticed that we changed the Tile from a class to a struct. This is a very important change, because we no longer need a memory reference to the Tile, since it's stored on the Stack memory segment. That's another 4 bytes of savings, or 500 MB total.

I'm assuming this is C# then? Presumably you have an array of Tile structs, in which case they exist in the heap (but in one single allocation, not millions of individual allocations), not the stack.

And now, a question for you:

How do you deal with world simulation of parts of the world that are outside the currently loaded section? Or, say, if an NPC near the edge of the loaded section, chasing the player, and then that section gets unloaded? Obviously what you need here depends on your gameplay, but it seems like it would be interesting to talk about.

In C++, it doesn't apply indeed, therefore my confusion. In c++ you allocate blocks of contiguous data for your arrays or objects. There is no differentiation between struct and class, except for the OOP programming constructs. An array is merely a pointer to the first element of the data allocated in memory.