3
\$\begingroup\$

I have a camera in my 2D side scrolling game and I want to implement the GUI. How can I do that?

For the moment, I draw everything like this:

spriteBatch.Begin(SpriteSortMode.Deferred, BlendState.AlphaBlend, SamplerState.AnisotropicClamp, DepthStencilState.None, RasterizerState.CullNone, null, scaleMatrix * camera.GetMatrix()); 
  player.Render(spriteBatch); 
  GUI.Render(spriteBatch);
  ...
spriteBatch.End(); 

Should I separate the GUI drawing code from the camera's transformation matrix? How can I do that? What is the best way to implement the GUI in a Windows Phone 8 project?

\$\endgroup\$
1

1 Answer 1

2
\$\begingroup\$

You could use a new begin and end set for the GUI. Doing this gets very slow if you use too many begin and end calls in a single frame. However, if you only have 2( one for world space and one for screen space ) it should be fine.

HOWEVER, I strongly suggest you ditch matrices for this. I find manually transforming vectors before I pass them to spriteBatch to be much better.

For example:

void Draw( SpriteBatch spriteBatch, Camera camera )
{
    // We perform all transformations on our position vector in camera.Transform.
    // This way we transform per sprite instead of per begin/end set.
    spriteBatch.Draw( texture, camera.Transform( position ), Color.White );
}

This will give you more control over what goes in what coordinate space. Matrices can be very easy and convenient to use, but in my opinion SpriteBatch doesn't work with them well.

\$\endgroup\$
6
  • 1
    \$\begingroup\$ Tempted to down vote for the off topic and oppinion based "SpriteBatch doesn't work with them well" part, but you do answer his question, even if you add what I think is bad advice afterwards. I find using a matrix a very robust and simple way to impliment a 2d camera and don't understand where the "not woking well" part comes from. \$\endgroup\$ May 1, 2014 at 16:39
  • \$\begingroup\$ @ClassicThunder That's your opinion. SpriteBatch needs a new begin/end call to pass a new modelView matrix. That's not good. What if you encapsulate draw in a class that would like to draw in multiple coordinate spaces? You'd need multiple begin and end calls, but then again how does the caller know you're begining and ending in that draw method? They don't. The "not working well" part doesn't come from matrices themselves, but the way sprite batch uses them. You often run into problems like the asker obviously did. \$\endgroup\$
    – Ben
    May 1, 2014 at 16:45
  • \$\begingroup\$ @ClassicThunder Having a uniform matrix per batch adds speed, but really takes away from the interface and makes the idea of a 2d scene graph next to impossible. \$\endgroup\$
    – Ben
    May 1, 2014 at 16:46
  • \$\begingroup\$ Everything I say is simply my opinion and I am not attempting to impose it just offer an opposing view. Your main issue seems to be the need for multiple sprite batches which I don't think is an issue and is fact I find it a good organizational tool for when you have multiple coord systems. It is something you have to take into account when designing the architecture but not an obstruction and doesn't limit the functionality. \$\endgroup\$ May 1, 2014 at 17:25
  • \$\begingroup\$ Ben, I've got to agree with @ClassicThunder. You're wrong. You're giving out bad advice. In the vast majority of cases passing a transformation matrix to Begin is preferable to manually transforming each and every Draw call. The primary reason, amongst many, is DRY..... Also, SpriteBatch does not work well for a proper 2D scene graph using either method. AND your code is broken for any camera matrix besides translation - a camera that scales is not atypical! (The OP has a scaling matrix in his question!) \$\endgroup\$ May 3, 2014 at 8:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .