Reported in version: HG 2.0
Reported for operating system, platform: All, All
Comments on the original bug report:
On 2017-09-14 22:35:50 +0000, Simon Hug wrote:
Created attachment 2945
Patch (draft) that adds the remaining custom blend modes to the opengl renderer.
Attached is a patch that adds support for the remaining custom blend modes to the opengl renderer. It also makes the loading of the OpenGL functions a bit more robust. In the current tip, it's possible that function loading fails (with an OpenGL 1.1 software renderer for example) and GL_ActivateRenderer calls GL_UpdateViewport which expects data->glViewport not to be NULL.
Other things the patch does:
Adds a SDL_RENDER_OPENGL_NPOT_TEXTURES hint. This hint can be set to 0 to make SDL always create power-of-two textures. Users can use that if they have drivers that just work better that way.
Sorts the function list in SDL_glfuncs.h by OpenGL version support and then alphabetically. GL_CreateRenderer expects the used functions in this list to be present after the context is created. Functions requiring OpenGL 1.2 and higher probably need to be handled in a more special way in GL_CreateRenderer.
Adds several checks for the OpenGL version when additional functions and extensions are loaded in GL_CreateRenderer.
Adds a check if context was made current on render destruction. If it failed, the memory will be freed without deleting the OpenGL resources. I'm guessing proper drivers will tear them down with the context so there should be no leaks.
I have done some minor testing but would like to do more over the next three days. This patch should be considered a draft. Comments are welcome of course.
During testing, I noticed that the Windows software renderer GDI Generic (on at least Windows XP) has some issues when the default framebuffer alpha size is 0.
Is it intentional that the renderer doesn't ask for an accelerated visual if the SDL_RENDERER_ACCELERATED flag is set?
On 2017-09-19 05:26:10 +0000, Simon Hug wrote:
Created attachment 2950
Patch (draft version 2) that adds the remaining custom blend modes to the opengl renderer.
I got some testing in on Linux on Windows (8.1 and XP) but plan to do some more.
Changes I made to the patch:
Corrected the reporting of GL_MIN and GL_MAX operation support. They are limited to the GL_ONE factors.
Had to rename some functions in the opengles2 renderer. They collided with the names from the opengl renderer and link.exe chose the wrong one.
On 2017-09-19 05:47:29 +0000, Simon Hug wrote:
Created attachment 2951
blendmodestest1.c is a test program for custom blend modes.
Created attachment 2955
Patch (draft version 3) that adds the remaining custom blend modes to the opengl renderer.
Windows 7 and 10 also got some testing. I'm currently just comparing OpenGL with Direct3D 11 and there seems to be an issue when selecting some alpha factors. For example (SRC_COLOR, ONE, ADD, SRC_COLOR, ONE, ADD) looks different. Is it possible that D3D11 doesn't support all combinations?
Changes I made to the patch:
Added an alpha size hint that allows controlling the alpha channel size on the default framebuffer of all OpenGL renderers. SDL didn't set any size and I got a framebuffer without alpha. The new blending modes can now interact with this and the difference to D3D11 (which always seems to allocate B8G8R8A8) is visible. The hint only activates if something is set because I'm not sure if existing applications rely on the default behavior.
This bug report was migrated from our old Bugzilla tracker.
These attachments are available in the static archive:
Patch (draft) that adds the remaining custom blend modes to the opengl renderer. (SDL2_DRAFT_add_opengl_blendmodes2.diff, text/plain, 2017-09-14 22:35:50 +0000, 56715 bytes)Patch (draft version 2) that adds the remaining custom blend modes to the opengl renderer. (SDL2_DRAFT_add_opengl_blendmodes4.diff, text/plain, 2017-09-19 05:26:10 +0000, 65572 bytes)Reported in version: HG 2.0 Reported for operating system, platform: All, All
Comments on the original bug report:
On 2017-09-14 22:35:50 +0000, Simon Hug wrote:
On 2017-09-19 05:26:10 +0000, Simon Hug wrote:
On 2017-09-19 05:47:29 +0000, Simon Hug wrote:
On 2017-09-21 09:39:06 +0000, Simon Hug wrote: