Hi,

Just a quick intro:
I was previously using VB and DirectDraw to write my 2D game and recently trying to re-code my game into XNA.

Currently, I need help in drawing my Tile-Based Map.

Eg: I have 2 textures
Texture2D Tileset;
Texture2D Map;

My map contains 40 x 30 tiles.

I know spritebatch can easily draw my map by drawing all the 1200 tiles every loop but that sounds quite inefficient to me.

Therefore, I would like to draw all my tiles onto the Map Texture first.
So that I only need to simply draw 1 texture every loop.

In DirectDraw, I can draw a Surface onto another Surface.
But XNA, I can't draw a Texture onto another Texture. Please help me.

In default mode, SpriteBatch batches all the Draw calls anyway, so you're probably better off just drawing all the tiles individually, and letting SpriteBatch batch them. This gives you a bit of free control, e.g. you can batch by texture, without having to code that - SpriteBatch will do it for you.

Personally I would just let SpriteBatch do it for me, and only worry about it later if I must eek out more performance.

But in response to your question - In Xna you draw into another surface using RenderTargets.

Hi Craig, I have some interests in this thing, can you write down some simple  example code?

I'd like to do some double/triple buffering drawing on a empty/generated texture and then draw it once on the screen or using this texture to apply some effects (zooming, rotating, transitional).

kittie:

Hi Craig, I have some interests in this thing, can you write down some simple  example code?

I'd like to do some double/triple buffering drawing on a empty/generated texture and then draw it once on the screen or using this texture to apply some effects (zooming, rotating, transitional).

Great, thanks!

Is this, in your experience, fast enough?

Thanks for the reply.
However, after trying RenderTargets, it seems to be quite useless to my application.

myTexture = myRenderTarget.GetTexture(); 

The problem is that the contents obtained by myTexture from this method will be gone if I were to make any other calls to SetRenderTarget again.

Most likely, RenderTargets is meant to be used inside the game loop only…
It might be useful if I need to perform some graphic operations on the texture but in my case, I does not need to. So it will be even worse (extra overhead). lol



Anyways, I’ll try to find if there’s a way to allow a texture to remember its content from the buffer permanently.

See my first post - you don't have to use render targets - spritebatch batches your draw calls anyway - all draw calls you make in between spritebatch.Begin() and spritebatch.End() are batched into one Draw call to the GPU (or one Draw call per unqiue Texture if you are drawing multiple textures).

kittie:

Great, thanks!

Is this, in your experience, fast enough?

For what I was using it for, yes it was fine.

Oh, I understand what you mean now. Only 1 actual draw when spritebatch.end? sounds great!

 

So even if my map has 2 layers (2400 tiles), the only overhead is the extra 2400 function call in my loop which should be insignificant in terms of performance I guess.

garloo:

Oh, I understand what you mean now. Only 1 actual draw when spritebatch.end? sounds great!

 

So even if my map has 2 layers (2400 tiles), the only overhead is the extra 2400 function call in my loop which should be insignificant in terms of performance I guess.

Thats it. There's probably a bit more overhead because the framework has to add each draw to it's internal batch. But it's quick. 2400 calls should be ok.

The first thing I would do is run this program through a sampling profiler (eg. NProf) and see exactly how long it is taking to draw these 2400 sprites.

Otherwise you're just guessing. Maybe it'll be too slow? Or maybe it'll be fine. I could guess which will be the case, but this would be just a guess, as it really depends on a lot of details that are unique to each piece of code and set of art content. The only way to find out for sure is to run the code and take some measurements. That will tell you whether you need to spend more time looking for a faster implementation, or whether what you have now is good enough.

Craig Martin:

kittie:

Great, thanks!

Is this, in your experience, fast enough?

For what I was using it for, yes it was fine.

Cool, I tried and it is really fast. Thank you!