We're rendering complex scenes and GUIs using hundreds of glLoadMatrixf calls just fine but when rendering just a few simple textured quads for some final overlays the correct order in which glLoadMatrixf calls are made seems to be ingored.
This is using an existing (and extensive) GUI system where GUI objects load a (modelview) matrix and perform their draw calls. I will load a matrix, make some draw calls, load another and make some more draw calls etc. What is happening (for example) is that sometimes the first batch of draw calls will be drawn as if with the second matrix! I've been trying different code paths such as using immediate mode, using glPush/glTranslate/glPop, using fixed function or vertex shaders and various other things but the erroneous behaviour persists, all I've been able to determine is that it seems pretty random. Sometimes the order in which I bind textures and make draw calls under the same matrix seems to affect the postion of the geometry.
I've seen this behaviour on 3 different systems using AMD graphics on windows 7 and 8.1, works as expected on the 4 different Nvidia systems tested. Before I go into more detail and spend more time on this (we're due to release a first version of the game to our Kickstarter backers at the end of this month), is it a known issue? Is there something I can do to make it work correctly? I can think of a few more things to try but they would mean making huge changes to a vast and complex GUI system, without any guarantee of success.
As a side note, on one of the systems tested the UI elements also looked bleached out, one of my collegues was able to restore them to their correct appearance by using an alternative OpenGL dll that reportedly fixes some AMD OpenGL issues. My guess is that this is related to the 3D scene being rendered using FRAMEBUFFER_SRGB while the GUI is not and uses RGB textures as opposed to SRGB. This aternative OpenGL dll did nothing to fix the main problem described in this thread.
Thanks,
Madoc