Howdy

Tile map rendering is a simple topic that has been around since the beginning of game development, but what about rendering them efficiently?

The basic approach I've taken so far is:

• Created a sprite Batch (batch by texture i.e no state change for large groups)
• Use a texture atlas dds created from my custom dds compiler in the editor
• Render only the tiles that are visible on the screen.
• Each tile consists of 16 bytes per vertex : x, y, u, v
• All tiles vertices are calculated and stored in a big Vertex Buffer
• Drawn to screen

so some optimization that can be done:

• using index buffers to reduce 8 bytes per quad
• Some how use a single quad and transform it and change UV coords for each "instance"

The issue is a index buffer will be the same data over and over 0, 1, 2 0,2,3 (made that up) accept because its one vbuffer it will go up and up and up even though in reality there are only 4 vert's just the position and UV changes.

The idea of instancing seems good, but how do you handle the positions and the fact that your UV's are different for the tile Index into the tile atlas?

Any-who, whats the general consensus from the wise gray-beards of graphics programmers? :D

Thanks

I'd guess the general consensus is going to be that you are probably much better off optimizing something else where it is more likely to make a notable difference, but other than that I can't really think of anything. :rolleyes:

Hmm you see i'm rendering around 1280 on a small 1024 x 720 res (its just a randomly chosen one) and the fps is averaging around 7 fps o.0. Ill do a per render Constant Buffer for view projection so thats handled on the GPU rather than CPU and update this on the results. The only thing the engine does atm is render these tiles so it is a pretty bad problem :unsure: .

Your problem is much more likely something else, like compiling a debug build or synchronizing the CPU and GPU (e.g. MAP_WRITE/MAP_READ instead of MAP_WRITE_DISCARD) if we're talking about such a serious perf problem.

Your problem is much more likely something else, like compiling a debug build or synchronizing the CPU and GPU (e.g. MAP_WRITE/MAP_READ instead of MAP_WRITE_DISCARD) if we're talking about such a serious perf problem.

MAP_WRITE_DISCARD is used in the Update Buffer on the graphics device, removed D3D11_CREATE_DEVICE_DEBUG, same issue. i think its more than likely the calculation of the vertices of each quad every frame which feels quite dumb as in calculating the top left,right and bottom right and left vertex position. The quad size never changes just the position and the uv's, so i need to find a way i can do the position and offset without recalculating every single quad.

I didn't mean D3D11_CREATE_DEVICE_DEBUG (though that can have a bit of impact), I meant the visual studio option for debug or release.

I didn't mean D3D11_CREATE_DEVICE_DEBUG (though that can have a bit of impact), I meant the visual studio option for debug or release.

Ah right im such an doughnut :D ive been programming for years in stuff like XNA, jumped to c++ engines like 6 months ago built a few but never used profiles till recently (after watching Mike Actions cpp con cache talks) so never took notice of the performance hit they have.

err right anyway its running at 1665 fps now lol, lessons learnt, time to finish the editor.... :)