I’m using Imgui as the UI for an overlay that hooks the renderer for either opengl 2 or dx9 games as such the renderer state found by imgui depends on the state the game leaves it in.
I’ve come across a situation where a relatively small minority (about 5%) of opengl games have textures screwed up.
It appears the games in question don’t clear/reset the states they change prior to my hook drawing ImGui. In this case meaning as textures are manipulated the actions are applied to the wrong texture stage.
After altering imgui_impl_opengl2.cpp function ImGui_ImplOpenGL2_RenderDrawData
From:
// Bind texture, Draw
glActiveTexture(GL_TEXTURE0); // This is defined in glext.h and may need to be setup with GetProcAddr on windows.
glBindTexture(GL_TEXTURE_2D, (GLuint)(intptr_t)pcmd->TextureId);
glDrawElements(GL_TRIANGLES, (GLsizei)pcmd->ElemCount, sizeof(ImDrawIdx) == 2 ? GL_UNSIGNED_SHORT : GL_UNSIGNED_INT, idx_buffer);
The Problem is fixed.
You’ll note the code in question is within the cmdlist loop,
you may get more mileage moving the active texture call outside that loop where the blend state is set etc.
To avoid altering my imgui source I have placed the active texture function above the call to ImGui_ImplOpenGL2_RenderDrawData in my own render code.
If this is something you wish to change (I appreciate the gl 2 stuff is quite a legacy api now) you may also wish to include store/restore of the active texture, as you have with the viewport and other settings.
Ah that may explain things then. I avoided the opengl3 implementation as per the readme.txt in the root of the imgui distribution:
example_glfw_opengl2/
GLFW + OpenGL2 example (legacy, fixed pipeline).
= main.cpp + imgui_impl_glfw.cpp + imgui_impl_opengl2.cpp
DO NOT USE OPENGL2 CODE IF YOUR CODE/ENGINE IS USING MODERN OPENGL (SHADERS, VBO, VAO, etc.)
Prefer using OPENGL3 code (with gl3w/glew/glad, you can replace the OpenGL function loader)
This code is mostly provided as a reference to learn about Dear ImGui integration, because it is shorter.
If your code is using GL3+ context or any semi modern OpenGL calls, using this renderer is likely to
make things more complicated, will require your code to reset many OpenGL attributes to their initial
state, and might confuse your GPU driver. One star, not recommended.
example_glfw_opengl3/
GLFW (Win32, Mac, Linux) + OpenGL3+/ES2/ES3 example (programmable pipeline).
= main.cpp + imgui_impl_glfw.cpp + imgui_impl_opengl3.cpp
This uses more modern OpenGL calls and custom shaders.
Prefer using that if you are using modern OpenGL in your application (anything with shaders).
it requires the use of shaders. The engine for the games I’m overlaying is always a fixed function one, whether dx9 or opengl2. Initially it was a case of keeping the difference between rendering methodologies as close as possible in the hopes of avoiding any major issues (even though the ff and programmable pipeline in theory should be usable in the same render thread).
I’ll give things a try with the imgui opengl3 implementation and let you know how I get on.
Basically imgui_impl_opengl2 aims to compile without an OpenGL loader, and GL_ACTIVE_TEXTUREglActiveTexture need those. OpenGL is a big mess honestly… and current situation with the back-end naming is not ideal. There’s probably a better way to handle all of that but GL back-ends have been draining a lot of energy already.
If you are overlaying most important is the functions you should could be supported by the GL context of the active app.
Yep, half the issues with gl come about through patchy docs and microsoft and others muddling the waters back in the day, not too sure what the situation is like with the modern stuff, hopefully better.
As you say that was another reason for going with imgui_impl_opengl2 as I didn’t want to add an extra dependency with a loader, when I didn’t really need to at the time. As it happens the games I’m overlaying use glext.h so looking at integrating that now with the imgui_impl_opengl3, just to see if that helps.
Thanks for the added info. Great work on ImGui been a lifesaver on this up to now.