   XNA textured quad vs sprite batch
  Hullo all, I am looking for a bit of advice, opinions, experience - any information is good information.I have a need for pushing lots of sprites around a screen in realtime - I have done some work putting a simple sprite engine together using XNA's sprite batch, not from any level of forethought but more because it seemed an obvious and simple next step - and I have already built a UI library on much the same principles. Thinking about what I need for the general swishy zoomy sprites I've realised that zooming in and out of a playfield would be a Good Thing, which started me thinking about whether something else other than sprite batch might be better.What I am wondering is whether its better to ignore the whole sprite batch thing, and instead work with a number of textured quads instead. Why ? I figure I can reap the benefits of scrolling and zooming ( and other cool stuff ) in a 3d environment, as opposed to a pure 2d approach. Whilst its possible to do it both ways, it just seems to me easier to do using textured quads. On the other hand, is that a bad idea from a resource management POV - by using textured quads do I needlessly push up the hardware required to run the code. And sure I can write some funky zooming and scrolling malarkey for spritebatch, but maybe I would be better off just having textured quads in the first place. I don't know how XNA handles sprite batches - are they textured quads themselves under the hood, or a simple blit, no fancy 3d shenanigans required. I can see there are pro's and con's for both approaches, I am leaning towards textured quads, but I am concerned I may be giving up a lot of nice optimised packaged functionality in sprite batch.So any opinions or experiences ? Pitfalls ? Doesn't matter ? Thanks for any input !   
Quote:Original post by beachballHullo all, I am looking for a bit of advice, opinions, experience - any information is good information.I have a need for pushing lots of sprites around a screen in realtime - I have done some work putting a simple sprite engine together using XNA's sprite batch, not from any level of forethought but more because it seemed an obvious and simple next step - and I have already built a UI library on much the same principles. Thinking about what I need for the general swishy zoomy sprites I've realised that zooming in and out of a playfield would be a Good Thing, which started me thinking about whether something else other than sprite batch might be better.What I am wondering is whether its better to ignore the whole sprite batch thing, and instead work with a number of textured quads instead. Why ? I figure I can reap the benefits of scrolling and zooming ( and other cool stuff ) in a 3d environment, as opposed to a pure 2d approach. Whilst its possible to do it both ways, it just seems to me easier to do using textured quads. On the other hand, is that a bad idea from a resource management POV - by using textured quads do I needlessly push up the hardware required to run the code. And sure I can write some funky zooming and scrolling malarkey for spritebatch, but maybe I would be better off just having textured quads in the first place. I don't know how XNA handles sprite batches - are they textured quads themselves under the hood, or a simple blit, no fancy 3d shenanigans required. I can see there are pro's and con's for both approaches, I am leaning towards textured quads, but I am concerned I may be giving up a lot of nice optimised packaged functionality in sprite batch.So any opinions or experiences ? Pitfalls ? Doesn't matter ? Thanks for any input !I do not know how actually XNA manages the SpriteBatch class (thought I suppose it use textured quads), but I can give you my hint about my experience rewriting the Sprite and Font class with SlimDX in C#. (the equivalent of yours in base DirectX). My opinion is that a rewritten class gives you more control about the state changes and optimization over the whole system. (the actual gain in performance is slim, but the gain in flexibility is high)Try to give a read here. I've already written two article over it. (the first over the Sprite class and the second over the Font class)http://feal87.wordpress.com/2009/05/31/scrapping-out-the-id3dx10sprite-id3dxsprite-interface/http://feal87.wordpress.com/2009/06/01/remake-of-id3dx10font-id3dxfont/I hope it will be of help in your choice.   ;  Behind the scenes the SpriteBatch is just producing textured quads with screen space coordinates.I tend to use SpriteBatch for any render target stuff I do (post processing, normal map generation, deffered shading), although I was previously using quads I'd produced myself.Why switch? SpriteBatch was there, and it did everything I need. If I'm using XNA I figured I might as well use the built in features.The only disadvantage to using a SpriteBatch over textured quads is that you can't do anything in the vertex shader - because the SpriteBatch uses it's own. Which is just a simple screen space transform of your position data, and then linear texture coordinates for the quad.I've never worked completely in 2D before (although it doesn't really exist anymore, as 2D is just 3D with everything having the same Z-value), but unless you want to use the vertex shader there shouldn't be any reason for you to stop using SpriteBatch.   ;  Thanks for the input - still a case for both I think then. Hmm.   ;  For reference, the SpriteBatch shader code can be found here.To elaborate on what I said earlier slightly.If you need to do anything using world space coordinates, set up your own quad system.If everything you need to do can be done in screen space coordinates, use the SpriteBatch.;  If I could do my last game over, I would use quads instead of Sprite Batch for the particle system weapons. No worrying about scaling and all that.Sprite Batch will always be great for GUIs though. =)   ;Quote:Original post by adt7To elaborate on what I said earlier slightly.If you need to do anything using world space coordinates, set up your own quad system.If everything you need to do can be done in screen space coordinates, use the SpriteBatch.I seem to be coming to the same conclusion with my XNA prototyping.  Trying to implement physics for a space RTS seems more difficult when trying to do everything in screen-space coordinates. :P   