Using (vanilla) shaders in GUIs breaks MalisisCore font rendering even after disabling shaders when BetterPortals is installed (even not in world)
Barteks2x opened this issue ยท 5 comments
I know this issue sounds completely insane and totally unrelated to what your mod is changing and to me it feels like there is no way this mod can possibly cause it. But it does and I can't figure out how.
This is what my GUI looks like with BetterPortals installed
Here is what is looks like with BetterPortals but my shaders not being used:
The shader is only being enabled for a short while when rendering the terrain preview box, and then disabled after that: https://github.com/OpenCubicChunks/CubicWorldGen/blob/ad8eab580f92ef6da161a79969db2c79ac715401/src/main/java/io/github/opencubicchunks/cubicchunks/cubicgen/common/gui/component/UIShaderComponent.java#L55-L61
Weirdly, vanilla font rendering works fine and changes some GL state (enabled slpha) and fixes MalisisCore on further calls, but after it renders next component, it switches back to "broken".
I'm completely unable to figure out what is the cause of this because there is seemingly no change in GL state from before and after doing my rendering with shaders, and yet not enabling shaders fixes the issue. There isn't even any change I can detect with glGetInteger (which according to opengl specification, should also work for float and boolean options) across frames, between frames with and without shaders enabled.
I know this issue sounds completely insane and totally unrelated to what your mod is changing and to me it feels like there is no way this mod can possibly cause it.
Actually, no, that sounds totally reasonable to me.
Vanilla shaders are broken in how they apply their blending state and BP tries to fix that.
My guess would be that it's one of:
- I've messed up the fix
- The terrain preview box or MalisisCore accidentally relies on the broken behavior
- It's the potential issue in GlStateManager.blendFunc/tryBlendFuncSeparate that is mentioned in the doc but which I haven't looked into in detail
- Any combination of the above
It's entirely possible that I accidentally reply on the broken behavior there. But I'm also not sure what would be the correct way to fix it or what the actual issue would be. If I can fix it by changing my shader json, great I can do that.
But if this is an issue that is actually in MalisisCore... there is no fixing it. MalisisCore is basically unmaintained now and while I'm planning to move away from it, it will take time.
As far as I understand it, you'd have to manually re-set the blending state after using the ShaderManager to whichever state is the expected one during GUI rendering.
The issue doesn't show up without BP because your ShaderManager is the only one being used at that time, so your JsonBlendState is the only one being used and therefore ShaderManager skips setting the blend state in the first place (thereby keeping it in the state it had before). That would also mean that it's actually not using the blend state specified in your json except for the very first frame.
BP's fix always sets the blend state, regardless of the previous shader (for the reason explained in the docs), so if you don't manually restore the GUI blend state afterwards, you'll be left with the blend state in your config.
Turns out I was just setting completely the wrong blending in my shader json, and vanilla just never applied my blending mode, so it worked. I fixed it now.
And actually, it did set that blending mode... for exactly one frame. And I could only see that frame when using mesa software renderer, because it happened so fast.