To Shader Hell and Back
As I'm starting to send out builds of Super Sky Sisters for people to test I'm slowly churning through bugs and crashes that I was completely unaware of until the game runs on different hardware. One of those crashes is caused by creating way too many shaders so I've been investigating on how to address that for now.
One big idea I had was to change how Otter uses shaders internally, but I think after some experiments this idea probably isn't going to work. The idea was to have Otter's Shader class keep a cache of compiled shaders instead of creating and compiling a new shader every time. Basically when making a shader it would check to see if an exact copy of that shader has already been created and compiled, and if so it would just use that one.
However that means that every sprite using the same shader would then also be sharing that shader's parameters. So if I wanted to change the color on an enemy, it would change the color on everything else as well. In order to get around that Otter's shader class would then have to manage and apply the shader's parameters before each render. So EntityA could set its parameters before rendering, and then EntityB could do the same.
I went down the rabbit hole a little bit with this technique but quickly found it performs like crap mostly. Iterating through every parameter per shader per entity per render becomes pretty chuggy pretty quickly. At first I thought this would be a pretty good idea since it would reduce hundreds of shaders to just 1, but the process of applying parameters before each render seems to be not the fastest thing in the world.
So now I'm back to the regular old way that Otter does shaders which is creates and compiles one for every shader instance. This has some downsides but I'm pretty sure it still ends up being faster than my experiment with a compiled shader cache.
I have some work ahead of me still to stop some of the crashes for Super Sky Sisters, but I'm pretty sure I know how to fix it it's just figuring out the right arrangement of code to implement the fix!
One big idea I had was to change how Otter uses shaders internally, but I think after some experiments this idea probably isn't going to work. The idea was to have Otter's Shader class keep a cache of compiled shaders instead of creating and compiling a new shader every time. Basically when making a shader it would check to see if an exact copy of that shader has already been created and compiled, and if so it would just use that one.
However that means that every sprite using the same shader would then also be sharing that shader's parameters. So if I wanted to change the color on an enemy, it would change the color on everything else as well. In order to get around that Otter's shader class would then have to manage and apply the shader's parameters before each render. So EntityA could set its parameters before rendering, and then EntityB could do the same.
I went down the rabbit hole a little bit with this technique but quickly found it performs like crap mostly. Iterating through every parameter per shader per entity per render becomes pretty chuggy pretty quickly. At first I thought this would be a pretty good idea since it would reduce hundreds of shaders to just 1, but the process of applying parameters before each render seems to be not the fastest thing in the world.
So now I'm back to the regular old way that Otter does shaders which is creates and compiles one for every shader instance. This has some downsides but I'm pretty sure it still ends up being faster than my experiment with a compiled shader cache.
I have some work ahead of me still to stop some of the crashes for Super Sky Sisters, but I'm pretty sure I know how to fix it it's just figuring out the right arrangement of code to implement the fix!
Post your comment!