Dev Log: To Batch or not to Batch
One of the things gnawing at me over the past few months is the rendering performance of Otter. So far it hasn't really been a problem, but I've only made a couple of low resolution prototypes and a game jam game with it so far. For my current project, a 1920 x 1080 resolution game, I started to worry about the rendering time as I add more and more assets to it.
So I was thinking "Hey maybe I can add some kinda sprite batching to Otter like XNA or Monogame has!" The basic concept is that it is very expensive to switch textures when rendering things with a GPU, so you take a bunch of sprites that all share the same texture and try to mash them together into one draw call from the video card. This way you can render all your sprites but you don't have to switch textures for every single one of them.
To start on this I basically tore down a bunch of rendering code in Otter. This was a few days ago, and since then I do have some sort of basic sprite batch working. In a little example I have 1000 sprites rendering with the same texture and as far as the video card knows it's actually only 2 renders... but so far I actually don't think this has affected performance at all!
I'm using SFML.Net for the core rendering of Otter. Everything that goes to the video card to show up on the screen goes through SFML's Draw functions. So far according to my small tests it seems that the video card isn't really having any issue switching textures a thousand times, but something before that is actually causing the slow down.
It seems that just going through and appending vertices to a vertex array in SFML.Net is just really slow. For example Otter's RichText class suffers from a pretty big performance hit if it's used to render a lot of text, like enough letters to cover the entire screen. This is pretty odd since RichText.cs in Otter is pretty much a copy of SFML's own text class from the C++ source! Almost the same code in C# runs almost 10x slower than C++, and of course this is not a big surprise since C# has a bunch of extra stuff with the managed memory and garbage collection. Still, it is pretty discouraging to realize. (Another tough one is the Tilemap class, which will suffer from big slow down during real time modification of a huge tilemap due to the rebuilding of the VertexArray!)
So right now I'm still reorganizing a bunch of code in Otter's rendering stuff. Hopefully the API will remain mostly unchanged, but right now my hope is that using texture atlases in Otter becomes smoother and actually has a performance benefit. Yay programming.
So I was thinking "Hey maybe I can add some kinda sprite batching to Otter like XNA or Monogame has!" The basic concept is that it is very expensive to switch textures when rendering things with a GPU, so you take a bunch of sprites that all share the same texture and try to mash them together into one draw call from the video card. This way you can render all your sprites but you don't have to switch textures for every single one of them.
To start on this I basically tore down a bunch of rendering code in Otter. This was a few days ago, and since then I do have some sort of basic sprite batch working. In a little example I have 1000 sprites rendering with the same texture and as far as the video card knows it's actually only 2 renders... but so far I actually don't think this has affected performance at all!
I'm using SFML.Net for the core rendering of Otter. Everything that goes to the video card to show up on the screen goes through SFML's Draw functions. So far according to my small tests it seems that the video card isn't really having any issue switching textures a thousand times, but something before that is actually causing the slow down.
It seems that just going through and appending vertices to a vertex array in SFML.Net is just really slow. For example Otter's RichText class suffers from a pretty big performance hit if it's used to render a lot of text, like enough letters to cover the entire screen. This is pretty odd since RichText.cs in Otter is pretty much a copy of SFML's own text class from the C++ source! Almost the same code in C# runs almost 10x slower than C++, and of course this is not a big surprise since C# has a bunch of extra stuff with the managed memory and garbage collection. Still, it is pretty discouraging to realize. (Another tough one is the Tilemap class, which will suffer from big slow down during real time modification of a huge tilemap due to the rebuilding of the VertexArray!)
So right now I'm still reorganizing a bunch of code in Otter's rendering stuff. Hopefully the API will remain mostly unchanged, but right now my hope is that using texture atlases in Otter becomes smoother and actually has a performance benefit. Yay programming.
Comments
Post your comment!