Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SDL_UpperBlitScaled ignores alpha #601

Closed
SDLBugzilla opened this issue Feb 10, 2021 · 1 comment
Closed

SDL_UpperBlitScaled ignores alpha #601

SDLBugzilla opened this issue Feb 10, 2021 · 1 comment
Labels
waiting Waiting on user response

Comments

@SDLBugzilla
Copy link
Collaborator

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

Reported in version: HG 2.0
Reported for operating system, platform: Linux, x86_64

Comments on the original bug report:

On 2012-06-14 16:33:21 +0000, wrote:

SDL_UpperBlitScaled is able to scale a surface and blit it, but it ignores the alpha value of the source surface. Instead of alpha blending, it blits the source surface with a white background.

Given:

SDL_Surface *target; // target surface, RGBA
SDL_Surface *src; // Contains RGBA surface
float scale = 0.5; // Scaling factor
SDL_Rect clip = {0,0,(int)(src->w * scale), (int)(src->h * scale)};

This blits it properly with alpha blending:

SDL_Surface *copy = SDL_ConvertSurface(src, target->format, 0); // Ensure that format matches
SDL_UpperBlit(copy, nullptr, target, &clip);
SDL_FreeSurface(copy);

This scales it, but alpha is ignored, giving a white background to blitted surfaces:

SDL_Surface *copy = SDL_ConvertSurface(src, target->format, 0); // Ensure that format matches
SDL_UpperBlitScaled(copy, nullptr, target, &clip);
SDL_FreeSurface(copy);

Additional Info:
SDL revision: 6328:9a65b2bd4e01

On 2013-02-21 14:11:22 +0000, wrote:

This bug doesn't seem to be isolated to Linux x86_64. I'm experiencing the same issue on WinXP/32, Win7/32 and Win7/64. For now, I've substituted SDL_SoftStretch() but there is a significant performance hit using this method.

I've been unsuccessful to date resolving the issue in source but the issue still exists in the latest source snap 2.0.0-6894 as well as trunk. Glad to help out with examples.

On 2013-03-01 01:08:29 +0000, Sam Lantinga wrote:

Yes, a simple example would be great. Thanks!

On 2015-05-06 19:39:00 +0000, Philipp Wiesemann wrote:

Maybe this is or was related to bug 2976.

On 2017-11-07 11:12:18 +0000, Sylvain wrote:

Created attachment 3073
test case

On 2017-11-07 11:12:39 +0000, Sylvain wrote:

Created attachment 3074
image

On 2017-11-07 11:20:56 +0000, Sylvain wrote:

Here's a testcase and it's image, tested on latest and also SDL 2.0.0. On ubuntu converting to ARGB8888 and RGBA8888.

It seems to me it SDL_UpperBlit and SDL_UpperBlitScaled behave correctly.
But with SDL_SoftStretch, Alpha is copied instead of being blended.

But two things seems wrong :

  • SDL_SoftStretch, Alpha is copied instead of being blended.

  • Depending on the position of SDL_UpperBlit :

    SDL_UpperBlit(surf, NULL, surf_target1, &clip); // Normal Blit
    SDL_SoftStretch(surf, NULL, surf_target3, &clip); // Aie, no scaled !
    SDL_UpperBlitScaled(surf, NULL, surf_target2, &clip); // Aie, no scaled !

or

 SDL_SoftStretch(surf, NULL, surf_target3, &clip);
 SDL_UpperBlitScaled(surf, NULL, surf_target2, &clip);
 SDL_UpperBlit(surf, NULL, surf_target1, &clip);  // Normal Blit

The following blit are scaled or not !
I'd say some "InvalidMap is missing somewhere ...

On 2017-11-07 11:25:32 +0000, Sylvain wrote:

SDL_SoftStrech() behave as if SDL_BLENDMODE_NONE was enabled on source surface, instread of SDL_BLENDMOD_BLEND

On 2017-11-07 12:40:11 +0000, Sylvain wrote:

Created attachment 3075
updated testcase

I got mistaken because UpperBlit modified the destination rect parameter. hence the strange behavior.

About, SDL_SoftStrech(), I think this is the default behavior looking at the code as it does a plain copy, no blending.

@SDLBugzilla SDLBugzilla added bug waiting Waiting on user response labels Feb 10, 2021
@1bsyl
Copy link
Contributor

1bsyl commented Feb 11, 2022

update testcase, testing SDL_SoftStrechLinear()
main_bug_1518_alpha_blitting.c.txt
img_bug_1518

For me this is ok, blending is done when scaling.
not when stretching

@1bsyl 1bsyl closed this as completed Feb 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
waiting Waiting on user response
Projects
None yet
Development

No branches or pull requests

2 participants