At this point of the process, with all the game play testing going on, I’m scanning the game for signs of things that make the frame rate hiccup. And at the same time I’m actually trying to break it with some of the test levels.
The good news is there’s just a few places where I’m seeing the frames skip a beat. So I headed over to the XNA….sorry…the “App Hub” boards and browse for optimization tips.
Turns out it’s best to keep a minimum number of sprite batch begin() and end() calls, as each one hits the performance a little. Good to know.
However, the bad news is, as far as I can tell. Certain things require new sprite batch calls to be executed and are unavoidable. Things like a change in the blend mode, or a pixel shader that uses a render to texture effect for an effect on the entire screen.
So, I spent some time last night scanning through all the draw statements and looking for ways to cut corners. I did catch one spot where I ended up drawing two copies of all the projectiles on top of themselves….which I wouldn’t recommend. And I think I caught one or two other places where I could merge a couple of sprite batches. But all-in-all, things were pretty tight.
I guess I’ll have to look somewhere else to untie my little performance knots.
Anyway….I just wanted to note. Since I misunderstood some earlier statements about sprite batches. Not only to you want to keep the number of sprite batches to a minimum, it’s ALSO the begin() and end() calls that slow things down a bit.
