D3DFORMAT issue

32-bit formats are the most efficient to use during rendering. The format of the actual image file is irrelevant; your images are decompressed and converted at load-time. So your 24-bit PNG will automatically be converted to a 32-bit A8R8G8B8 format (if that's the format you specified).

Rather than guessing where the performance problem lies, I suggest using a profiling tool such as PIX or NVPerfHUD to find out what's causing the slowdown.

Conversion is what I would expect. So perhaps the suggestion given to me was incorrect? Ah, and thanks for pointing out a profiler, I knew I was going to need one, but a 30 day trial of VTune didnt have me jumping at the chance to get it. Does anyone have any quick suggestions on what could be giving me such a huge performance hit? I would expect that I could render a bunch of 2d images without dipping below 60 fps at the worst... I realise there could be a lot of factors, but I've at least narrowed it down to the level images on screen.

As Sc4Freak suggested, use PIX. It comes with the SDK, you can set it to delay gathering info to a specified frame count, etc. It'll tell you how long each call takes and should pretty quickly tell you where the time is being taken up.

Thx guys, I'm looking into PIX, PerfHUD looked like overkill for now.

Dropping from 200 to 50 doesn't actually sound too unreasonable. Remember that frame rate is non-linear (although in this case, 5ms to 20ms versus 200fps to 50fps is still a factor of 4 [lol]). The point, however, stands that if you're rendering a blank screen you're not really doing any useful work thus comparing it to when you are doing some useful work is largely meaningless. What you want to know is the difference between doing some meaningful work and more meaningful work.

Given bottlenecks and overheads you might find that rendering 0 tiles is 200fps, 100 tiles is 50fps but 1000 tiles is 45fps. You can then try to guesstimate how much effort is involved in rendering individual tiles, cross reference that against how many tiles you want or need to render and map that to your target hardware - then you'll know whether you actually have a problem.

But, all that said, I don't suppose you're rendering each tile with its own Draw**() call, or using a new ID3DXSprite per tile are you? Such code is quite common for people implementing 2D tile games in D3D and the resultant high number of draw calls is usually the key problem...

hth
Jack

Ah, yes I see... I was calling my own draw function for each tile which set verticies, set textures, and called DrawPrimitive() (which i believe you are referring to). I need to rearrange this so I can call DrawPrimitive() once for each tile texture. Perhaps a multimap is in order....

If that is how you've written your renderer then, yes, you will most likely get a sizeable performance improvement for redesigning it.

Try to set it up with shared vertex and index buffers (remember, you don't have to draw every vertex in a call - understanding and utilizing the DrawIndexedPrimitive() parameters properly is a great idea) and trying to despatch as many tiles in one draw call is also a good approach. This can be tricky if each tile is on its own texture so consider using "texture palettes" (aka "texture atlas") to combine multiple small textures onto one larger one.

Best of luck!
Jack