Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


We're also offering banner ads on our site from just $5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Creating custom SpriteBatch class in SlimDX. Pseudo-code or design notes question.


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
4 replies to this topic

#1 CdrTomalak   Members   -  Reputation: 272

Like
0Likes
Like

Posted 29 October 2012 - 08:39 AM

As part of a programming exercise I'm looking to create my own SlimDX SpriteBatch class, based on that found in XNA.

I've already laid the foundations, with a working (but inefficient) sprite class for a single sprite. I am happily re-using this in my game, but I know it's probably horrifically inefficient compared to the XNA SpriteBatch class.

Can anyone point me in the direction of design notes for this? I know I could just re-use someone else's code, but I'm really keen to have a go myself.

Thanks in advance Posted Image

Sponsor:

#2 Mike.Popoloski   Crossbones+   -  Reputation: 2919

Like
2Likes
Like

Posted 29 October 2012 - 11:25 AM

What exactly are you looking for? There's always the standard things to mention, such as buffering up changes into a dynamic vertex buffer, sorting things by depth or by texture (depending on alpha blending), and making sure your memory access patterns are good.
Mike Popoloski | Journal | SlimDX

#3 CdrTomalak   Members   -  Reputation: 272

Like
0Likes
Like

Posted 29 October 2012 - 02:00 PM

Hi Mike - thanks for the post.

Specifically I'm looking for at the least recommended class attributes and methods. From what I can tell after initialisation of the SpriteBatch class, as you prepare to render a frame you 'Add' sprites by invoking the SpriteBatch.Add method, passing the vectors in the form of a rectangle, and the texture for that sprite. As I understand it, this necessitates the dynamic vertex buffer, such that we can draw all sprites via only one draw call - as opposed to reloading vertex buffers with a new data stream per sprite.

I guess I could derive the pseudo-code for the SpriteBatch from a paragraph or two - but as you can tell really I want to nail down the principles of operation before I start coding it.

At the moment I have a Sprite class which contains a vertex buffer, index buffer, and vertices data stream. It has a draw method, meaning at the moment if I want 100 sprites then I've got 100 draw calls for each Sprite object. Instead of this (which is clearly horrifically inefficient - but works...) I want a single draw call - somehow - and the answer is SpriteBatch, I think. Is this right?

#4 MJP   Moderators   -  Reputation: 11569

Like
1Likes
Like

Posted 29 October 2012 - 03:48 PM

The ideal implementation depends a bit on what hardware and D3D version you're targeting. Dynamic vertex buffers work fine, but on newer GPU's you can also make use of instancing and geometry shaders to allow the CPU to do less work.

I know that you said you don't want code, but if you'd like you can take a look at the SpriteBatch implementation that Shawn Hargreaves made for DirectXTK. It could at least give you idea of the kinds of optimizations that are possible.

#5 CdrTomalak   Members   -  Reputation: 272

Like
0Likes
Like

Posted 30 October 2012 - 03:50 AM

I'm using DX11, but I've not read about instancing and geometry shaders much I must admit. I use some basic shader code, which doens't do anything clever.

Thanks for the pointer to the SpriteBatch implementation I'll take a look.

I'm also going to take a look at Nico Shertlers implementation: http://nicoschertler.wordpress.com/projects/

Cheers




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS