Fix for issue #847, "SamplerStates aren't properly applied when active texture changes"#889
Conversation
|
As a workaround, I had temporarily made the dirty checks always pass in my local working copy of MonoGame, which made the sample states be correctly updated but was very slow since it meant the state were reset every time. I just merged your commit in my own repository and I can confirm it seems to work properly (and gives much better performance that my workaround). So +1 for pulling this and thanks! |
|
We'll test this today and report back. |
|
OK, cool. FYI, as I mentioned earlier, while this change is functional it is likely there is a more elegant way to do it. It is efficient compared to resetting the state every time, but it causes up to N extra glActiveTexture() calls for each draw where N SamplerState slots have changed, or N textures have changed. If the work could be integrated with TextureCollection.SetTextures(), we could avoid that. It also always loops over every sampler state slot (which can be like ~30) for each draw. I have not attempted to make a change that addresses these issues myself, it seems like it would be more involved. Basically TextureCollection & SamplerStateCollection would need to share knowledge when rendering with GL. I think it is possible though. |
|
Looks straight on iOS. |
|
If Steve agrees lets get this merged. |
|
Tom, what are your thoughts on Scottish comments about TextureCollection |
|
Damned auto correct. Scott's comments I meant. |
|
I agree... they should share info or maybe the application of texture/sampler state should occur in a single central location like GraphicsDevice. Still since this works right now and the other changes don't exist yet... we should probably merge the initial fix first. |
|
Ok. I'm cool with that. |
|
This needs to be updated before we can merge |
|
Merged the latest from this repo's develop3d into my branch, hope that does it. |
|
Yep... fixed. Merging. |
Fix for issue #847, "SamplerStates aren't properly applied when active texture changes"
6 participants
What we would consider sampler state in D3D is stored per-texture in GL, so you have to have the correct active texture unit & texture bindings active before you call glTexParameter within SamplerState.Activate().
This change stores the "last SamplerState used" on the Texture instance, to avoid redundant glTexParameter calls.
It's possible this might make some redundant glActiveTexture parameters in cases where you use a single texture with frequently changing sampler states, maybe there is a better way to design this... it would be nice if it was somehow integrated with the related loop in TextureCollection.SetTextures().