I asked this because I don’t know how this should work before shader generator was invented. I can say that I’ve tried every possible available way the API offers, i.e. loader.unloadShader, ShaderPool.releaseAllShaders, and Shader.make. They just don’t work. Looking at the source, it seems that the shader pool insists in loading a shader only once, regardless of calling releaseAllShaders.
I believe there must be a correct way.
For now, I live with inefficient solution.
Thanks.
Hmm. Josh designed the shader loading code, so I’m about as much in the dark about its intended use as you are. But looking at the code, it does appear that ShaderPool::release_all_shaders() should completely empty its cache, thus forcing the next attempt to load particular shader to hit the disk again. Is this not the behavior you observe?
What, precisely, do you mean when you say you want to reload a shader? Are you talking about forcing it to recompile and reload onto the graphics card, or are talking about re-reading the disk file that defines it?
David
What I meant by reload is re-read, recompile, and reupload. There is no disk hit after release, the next load returns exactly the same shader object at the same mem address.
Really? How strange. It’s not clear how that’s possible, given that release_all_shaders completely empties the cache of previously-loaded shaders. Unless that call to _shaders.clear() is failing somehow.
You said you saw from looking at the source that the code is designed to hold onto the shaders forever? I don’t see that. What were you referring to?
David
I just took a quick peek and don’t know how I came to that conclusion. The failing clear() is the closest suspect, since I also experience the same failure for StringStream, so I had to use setData(’’) to clear it.
EDIT :
oh, I was wrong again, I called Ios’ clear instead of SS’ clearData.