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

Handling of alpha channel in Altivec accelerated blit functions #664

Closed
SDLBugzilla opened this issue Feb 10, 2021 · 0 comments
Closed

Handling of alpha channel in Altivec accelerated blit functions #664

SDLBugzilla opened this issue Feb 10, 2021 · 0 comments

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: 1.2.15
Reported for operating system, platform: Mac OS X 10.5 (PPC), PowerPC

Comments on the original bug report:

On 2012-02-19 09:38:21 +0000, wrote:

Created attachment 823
SDL_blit_N.patch

There is only one Altivec accelerated blit function (ConvertAltivec32to32_prefetch() or ConvertAltivec32to32_noprefetch(), depending on the CPU used) that is supposed to handle all alpha combinations. This works as follows for every pixel line:

  1. Blit single pixels until an aligned address is reached
  2. Accelerated blit as far as possible
  3. Blit single remaining pixels
    Part 2. is set up correctly to handle different combinations of the alpha channels of the participating surfaces. Parts 1. and 3. only do a simple copy of all the pixel's components from souce to destination. But when the source surface has no alpha channel (Amask is 0, e.g. the video surface) the surface's alpha value must be used instead. Otherwise crap (uninitialized data) is being copied to the destiniation's alpha channel.

The attached patch is a quick'n'dirty solution to the problem. A more sophisticated solution might require separate functions for different combinations of the alpha channels of the participating surfaces.

The problem seems not to come up when the width of the destination surface enforces all pixel lines to start at an aligned address. This can easily be accomplished by using a suitable pitch value for all surfaces, but SDL_CreateRGBSurface doesn't make use of this right now.

On 2012-02-20 17:57:25 +0000, Sam Lantinga wrote:

Fixed, thanks!
http://hg.libsdl.org/SDL/rev/7a2e0f7b30cb

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant