OpenGL: Transition glitched on NVIDIA GPUs (Proprietary Driver)
On an NVIDIA GPU, the transition effect looks glitched with the OpenGL 1.5 and OpenGL ES 2.0 renderers
https://github.com/user-attachments/assets/c8f1fd31-0158-4a7f-b2c7-581874806b74
OS: Arch Linux (6.12.34-1-lts) CPU: AMD FX-4300 (Yes I know this CPU is terrible) GPU: NVIDIA RTX 3050 8GB (nvidia-lts 575.64)
As best I can tell this happens because it is presenting the back buffer without waiting for a call to SDL_GL_SwapWindow(). If you remove the m_dirty guard you get the same effect on other system. This could be because double buffering is disabled at a driver level but I'm not sure.
void OpenGL1Renderer::Flip()
{
if (m_dirty) {
SDL_GL_SwapWindow(DDWindow);
m_dirty = false;
}
}
Does this also happen in windowed mode? It would be good if someone on Windows can also test this.
Does this also happen in windowed mode?
In the video, I have it in windowed mode
Also happening on AMD.
GPU0:
apiVersion = 1.4.305
driverVersion = 25.0.5
vendorID = 0x1002
deviceID = 0x73df
deviceType = PHYSICAL_DEVICE_TYPE_DISCRETE_GPU
deviceName = AMD Radeon RX 6750 XT (RADV NAVI22)
driverID = DRIVER_ID_MESA_RADV
driverName = radv
driverInfo = Mesa 25.0.5-2
conformanceVersion = 1.4.0.0
deviceUUID = 00000000-0800-0000-0000-000000000000
driverUUID = 414d442d-4d45-5341-2d44-525600000000
https://github.com/user-attachments/assets/99c1020f-a754-4d3e-acb8-7dcd6ef89870
Interesting since it's not happening on Radeon 7800xt using radv
Happens on macOS too (OpenGL 1.1, M2 Macbook Pro)
https://github.com/user-attachments/assets/b8bc56eb-7496-40ff-9b90-027bbe384e87
Transition works perfectly on SDL3_GPU and Miniwin (software) emulation, so must be an issue with ogl shaders (if that is in fact how the transition works, I need to look)
like the title says this is specific to OpenGL and only on some systems. It requires read back and controlled double buffering.
The OpenGL 1.1 HAL is completely missing now in c63d725 with the same compiler setup on macOS.
like the title says this is specific to OpenGL and only on some systems. It requires read back and controlled double buffering.
Or it just never worked because the mingw-w64-x86_64-freeglut and mingw-w64-x86_64-glew packages aren't pulled for the Windows builds by the Github Action.
The OpenGL 1.1 HAL is completely missing now in c63d725 with the same compiler setup on macOS.
Open an issue for it instead of mentioning it in other random issues. Bonus points for identifying which commit caused it to no longer show up.
Or it just never worked because the mingw-w64-x86_64-freeglut and mingw-w64-x86_64-glew packages aren't pulled for the Windows builds by the Github Action.
That's about having OpenGL as an option in the first place, not weather it has issues with transitions. My cars tires are also flat, cause I don't have a car.
like the title says this is specific to OpenGL and only on some systems. It requires read back and controlled double buffering.
Or it just never worked because the mingw-w64-x86_64-freeglut and mingw-w64-x86_64-glew packages aren't pulled for the Windows builds by the Github Action.
That's about having OpenGL as an option in the first place, not weather it has issues with transitions. My cars tires are also flat, cause I don't have a car.
Can't be working on "some systems" if it's not properly compiled in the first place for what you're testing for. The problem with not having a proper Isle-config for Windows is that you can't see whether or not the option you're trying to set in the .ini file is actually valid and not just defaulting to another option.
Yes that's why I created this issue: https://github.com/isledecomp/isle-portable/issues/337 , since I don't have Windows I'm not able to solve it. please keep comments .
This should now be solved, please let us know if the issue persist in the new builds.
It's fixed for me