| Summary: | Propose new blend mode, SDL_BLENDMODE_BLEND_DSTA | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Trygve Vea <trygve.vea> |
| Component: | video | Assignee: | Sam Lantinga <slouken> |
| Status: | RESOLVED FIXED | QA Contact: | Sam Lantinga <slouken> |
| Severity: | enhancement | ||
| Priority: | P2 | CC: | sylvain.becker |
| Version: | 2.0.3 | ||
| Hardware: | x86_64 | ||
| OS: | Other | ||
| Attachments: |
Implements SDL_BLENDMODE_BLEND_DSTA on opengl, d3d, d3d11, and gles2 w/o shaders renderers.
screenshot |
||
This is implemented for accelerated renderers in this commit: https://hg.libsdl.org/SDL/rev/180e8906dc3c I think this is what you want: blendMode = SDL_ComposeCustomBlendMode(SDL_BLENDFACTOR_SRC_ALPHA, SDL_BLENDFACTOR_ONE_MINUS_SRC_ALPHA, SDL_BLENDOPERATION_ADD, SDL_BLENDFACTOR_ZERO, SDL_BLENDFACTOR_ONE, SDL_BLENDOPERATION_ADD); Implemented! Just wondering: could this has introduced an issue within opengles2 renderer ? I think I start to see pink colorkey with this commit. (and not when switching to opengles, or opengl). It's possible, can you back out the commit and see if that fixes it? have tried yet, but this can be reproduced with testspriteminimal.c SDL_SetHint(SDL_HINT_RENDER_DRIVER, "opengles2"); indeed, hg update -r 42b62c737891 is ok hg update -r 180e8906dc3c is bad : wrong display when using opengles2 Interesting, I'm not seeing that here. OpenGLES renderer is fine with testspriteminimal and testsprite2. Could it be a different screen format that's causing problems? This is not OpenGLES 1 (which is fine) but OpenGLES2 ! For testspritemininal, I dont see pink, but white background (instead of transparent). see screenshot Created attachment 2852 [details]
screenshot
I haved tested with opengles1 on deskop (it fallback to opengl). But I tested it on android. so on desktop : - opengl = ok - opengles2 = fail on android : - opengles = ok - opengles2 = fail oops: I haved *not* tested with opengles1 on deskop (it fallback to opengl). But I tested it on android. I think the issue is in GLES2_SetupCopy() it may be : GLES2_SetBlendMode(data, texture->blendMode); and not GLES2_SetBlendMode(data, renderer->blendMode); And also some warning when compiling application:
include/SDL2/SDL_blendmode.h:68:46: warning: commas at the end of enumerator lists are a C++11 extension [-Wc++11-extensions]
SDL_BLENDOPERATION_MAXIMUM = 0x5, /**< max(dst, src) : supported by D3D11 */
^~
include/SDL2/SDL_blendmode.h:86:46: warning: commas at the end of enumerator lists are a C++11 extension [-Wc++11-extensions]
SDL_BLENDFACTOR_ONE_MINUS_DST_ALPHA = 0xA, /**< 1-dstA, 1-dstA, 1-dstA, 1-dstA */
Fixed, thanks! |
Created attachment 1693 [details] Implements SDL_BLENDMODE_BLEND_DSTA on opengl, d3d, d3d11, and gles2 w/o shaders renderers. Hello, I want to propose a new blend mode (SDL_BLENDMODE_BLEND_DSTA), which is based on SDL_BLENDMODE_BLEND, but without modifying the destination alpha. The use case for this is when I am rendering to a texture containing an irregular shape - and do not want to modify the alpha channel of the destination target. I need something like this for a project I'm doing, but I would prefer to not maintain my own patchset if I can avoid it. I've attached a patch, which I've tested on Linux with the OpenGL renderer - however, the patch does contain code that I _THINK_ will work with d3d, d3d11, and gles2 without shaders as well - these are currently untested, but I left them in as the code looks pretty straight forward. I looked briefly through SDLs website without finding any information of how you deal with third party patches - but I would gladly make any necessary modifications to help get this merged, if you would accept it. Regards -- Trygve Vea