Where does SpriteBatch get its 'quad' from?

Feb 14, 2015 at 5:21 AM
Edited Feb 14, 2015 at 5:26 AM

In my previous (very beginner) dealings with directX 11 I would create a quad with 4 vertices like
quad.v[1].y ..

etc and texture it. I was getting to confused when it came to a font engine, and found the DirectX TK for that. I have ended up using it for pretty much all sprite rendering too (and audio), but I would like to revisit how its actually doing it.

I would like to know where SpriteBatch creates the 'quad' of which it textures. I have stepped into the code but cant quite figure out where it is happening.

Id also like to thank the authors because without the DirectX TK I would be a lost soul.
Feb 14, 2015 at 7:38 AM
Edited Feb 14, 2015 at 7:39 AM
The index buffer is set up in SpriteBatch::Impl::DeviceResources::CreateIndexValues and is set up to take each four vertices in the VB and form two triangles from them.

In SpriteBatch::Impl::RenderSprite the SpriteInfo records it makes for each sprite draw request are converted into the four vertices.
Marked as answer by walbourn on 2/13/2015 at 11:38 PM
Feb 15, 2015 at 1:34 PM
Hi walbourne,

Thanks for your reply. I located those sections in the code and now can see what I was after.

I have another question. I have got a basic particle system using SpriteBatch. It is working fine with no performance problems (Unless I crank up the particles to a ridiculously large amount) , but I remember reading under feature level notes for SpriteBatch "For more extreme usage scenarios (large particle systems, star fields, etc.), writing a custom sprite implementation is likely the better solution over using SpriteBatch."

I am just wondering what roughly is meant by that line.

Feb 15, 2015 at 10:04 PM
Basically if you aren't getting good enough performance from SpriteBatch, consider writing something more specialized for your scenario. SpriteBatch is extremely useful, but also general. When pushing a few tens to hundreds of thousands of particles, a dedicated solution is better.