The thing is that I need to draw different images with different parameters and I have 3 of those calls at one Draw call. Is that resource-heavy?
It shouldn’t be a problem on any device. You can work around this by using SpriteSortMode.Immediate, as it gives a level of flexibility compared to Deferred mode.
1 Like
the problem isn’t in the SpriteSortMode
for example, I have 3 images: background, some image that infinitely floats in the screen (like clouds that just pass by) and sprite that is scaled over time.
for bg: (SpriteSortMode.Deffered, alpha blend = null, SamplerState.LinearClamp);
for floating image: (SpriteSortMode.Deffered, alpha blend = null, SamplerState.LinearWrap);
for scaled sprite: (SpriteSortMode.Deffered, alpha blend = null, SamplerState.PointClamp);
So thats why I have to call spriteBatch.Begin() and End() over and over again and that’s exactly why I am concerned whether that takes a lot of computing power or not.
I don’t suspect that is resource heavy (definitely not 3 different sets - I have a dozen or more).
However if there was loads of texture switching and device state changes throughout each loop, I’m thinking you’d start to notice an fps drop (if testing with fixed step off).
If I’m not mistaken; these device states are actually set when calling End(). You could benchmark it to see what kind of performance difference it makes (turn off vsync, isFixedTimeSetep, and apply - but immediately after setting the device in game1 constructor - then use average fps display).
If you think it’s worth it - you could roll your own version so that you have other options - maybe can set device states differently(primitive intervals) - however I’m not sure how much difference it makes since I think you still need to render out primitives in groups with common device states [which is basically what it does already]
If you weren’t using colors for a type of sprite for example, you could use a different vertex declaration (and slightly different shaders to match) - however I suspect it would only make a few fps difference (ie: 300fps vs 303fps)
I think minimizing texture switching would be the biggest thing (ie: stitch everything together into huge spritesheets if possible) – then you could create a version of begin-end which only sets minimal possible device changes and use sourceRects to generate uv cords(like spritebatch) [and preset indices]. Then just making sure you set textures in an order that minimizes switching, you wouldn’t need to code it to sort them(a small optimization) [also I would use a font texture this way too].
1 Like
Three is a very low number of SpriteBatch Begin/End pairs, and as AlienScribble has described it is just one of several factors that can affect rendering performance.
3 Likes
Thank you all guys! I appreciate your help!