Found actual bug in the Alpha-blit code

Just wanted to let you know that I did find an actual
bug in the Alpha-blit code (beyond simple rounding
errors)…

I made a patch to help reproduce the problem that you
can download from here:

http://icculus.org/~loren/SDL_alpha-bug-demo.patch.gz

My comments on the patch are as follows:

Here is an SDL patch that demonstrates a bug
in the blitting code. My patch that I posted
last week doesn’t (yet) fix the problem.

  • The patch simply cycles the “light” in
    the testalpha program through 4 different
    intensities when you click on the right
    mouse button.
  • The bug appears in the form of a green
    fringe around the edge of the “light”
    when blitting a darker “light” onto a
    lighter background.
  • I think I have tracked the bug down to
    division not being a legal operation on
    twos-compliment negative numbers.
  • I don’t currently have a fix for the
    bug, but I will look into this soon.

Sorry to be the barer of bad news, but I will look
into this ASAP…

-Loren__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup

Hmm… well it looks like I jumpped the gun on this…
there are some errors that can propigate but basically
dividing a n-bit 2’s compilment number by 2^m is a
special case that yeild a (n-m) bit 2’s compliment
number… Like I said the math isn’t dead-on, but I
think that the errors stay below 0.7%…

Basically why I’m going over the blitters with a fine
tooth comb, is I want to ad support for pre-multiplied
alpha channels (as a different format, such as RLE),
and dual-alpha blending. I’d also like to add a
SDL_BlitBehindSurface() function that uses RLE
optimization, to help facilitate fast front-to-back
composition.

I’m still working on a patch, but I want to know how
people expect combinations of the following operations
to behave. Also I want to hear any comments on
changing the behavior of SDL with regard to these
features and how they act in combination. (I want to
avoid breaking existing applications ass much as
possible).

Feature Current behavior


Blitting between Dest surface alpha channel
2 surfaces with preserved, but ignored durring
alpha channels blit.

Blitting from a Works as expected, but not
surface with an combinable with surface alpha
alpha channel (unsure of color key)

Blitting from a Works as expected, but not
surface with a combinable with surface alpha
surface alpha (unsure of color key)

Blitting from a Works as expected, but unsure how
surface with a it combines with other features.
color key

Thanks in advace for any comments,

-Loren

— Loren Osborn <@Loren_Osborn> wrote:

Just wanted to let you know that I did find an
actual
bug in the Alpha-blit code (beyond simple rounding
errors)…

I made a patch to help reproduce the problem that
you
can download from here:

http://icculus.org/~loren/SDL_alpha-bug-demo.patch.gz>

My comments on the patch are as follows:

Here is an SDL patch that demonstrates a bug
in the blitting code. My patch that I posted
last week doesn’t (yet) fix the problem.

  • The patch simply cycles the “light” in
    the testalpha program through 4 different
    intensities when you click on the right
    mouse button.
  • The bug appears in the form of a green
    fringe around the edge of the “light”
    when blitting a darker “light” onto a
    lighter background.
  • I think I have tracked the bug down to
    division not being a legal operation on
    twos-compliment negative numbers.
  • I don’t currently have a fix for the
    bug, but I will look into this soon.

Sorry to be the barer of bad news, but I will look
into this ASAP…

-Loren


Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup

[…]

I’m still working on a patch, but I want to know how
people expect combinations of the following operations
to behave. Also I want to hear any comments on
changing the behavior of SDL with regard to these
features and how they act in combination. (I want to
avoid breaking existing applications ass much as
possible).

Sounds interesting, but I’m a bit worried about things like “blit behind” and “dual alpha channels”…

AFAIK, the basic idea with SDL is that it should just wrap functionality that can be expected to be hardware accelerated. More specialized stuff that can only be implemented in software doesn’t belong in SDL, but should be implemented in libraries on top of it, or directly in application code.

That said, premultiplied alpha (which enables blending with alpha channel AND surface alpha) is accelerated by pretty much every video card these days. Although glSDL is the only way to get accelerated alpha blending with the SDL API right now, the feature is available in DirectX, OpenGL and some other “new” APIs, so of course, it would definitely make sense to support it in a future version of SDL.

Either way, the software blitters will always be needed, for portability, and for covering situations where existing h/w acceleration can’t be used for whatever reason.

//David

.---------------------------------------
| David Olofson
| Programmer

david.olofson at reologica.se
Address:
REOLOGICA Instruments AB
Scheelev?gen 30
223 63 LUND
Sweden
---------------------------------------
Phone: 046-12 77 60
Fax: 046-12 50 57
Mobil:
E-mail: david.olofson at reologica.se
WWW: http://www.reologica.se

`-----> We Make Rheology RealOn Wed, 19/06/2002 14:05:06 , Loren Osborn <linux_dr at yahoo.com> wrote:

Well… Adding BlitBehind is certainly something
debatable. I felt it belonged there because it
reached into some low level SDL stuff… It could
certainly be implimented externally, but It would
probably need to be updated any time the SDL RLE or
alpha blitters change. My intent was to keep this in
SDL so that it could all stay in sync.

As far as “dual alpha channels”, this is already in
SDL… It just doesn’t behave as I believe it should.
The current behavior is it blits as if the dest is
opaque, but retains the dest’s alpha data. I don’t
think that this is the expected behavior

Also, as far as I know, mixing surface alpha with
alpha channel with color-keys seems to not be
disallowed in the API, but I don’t think that the
behaviors are predictable, or at least what is
expected… How SHOULD SDL behave when it’s told to
set the surface alpha on an RGBA surface???

— David Olofson <david.olofson at reologica.se> wrote:

[…]

I’m still working on a patch, but I want to know
how
people expect combinations of the following
operations
to behave. Also I want to hear any comments on
changing the behavior of SDL with regard to these
features and how they act in combination. (I want
to
avoid breaking existing applications ass much as
possible).

Sounds interesting, but I’m a bit worried about
things like “blit behind” and “dual alpha
channels”…

AFAIK, the basic idea with SDL is that it should
just wrap functionality that can be expected to be
hardware accelerated. More specialized stuff that
can only be implemented in software doesn’t belong
in SDL, but should be implemented in libraries on
top of it, or directly in application code.

That said, premultiplied alpha (which enables
blending with alpha channel AND surface alpha) is
accelerated by pretty much every video card these
days. Although glSDL is the only way to get
accelerated alpha blending with the SDL API right
now, the feature is available in DirectX, OpenGL and
some other “new” APIs, so of course, it would
definitely make sense to support it in a future
version of SDL.

I’m interested in implementing it as another data-mode
such as RLE… also interested in being able to
combine it WITH RLE, so you can have an RLE surface
with premultiplied alpha data. If you have any glSDL
code along these lines, I would very much like to see
it…

Either way, the software blitters will always be
needed, for portability, and for covering situations
where existing h/w acceleration can’t be used for
whatever reason.

Hisotrically I think that we’ld find software blitters
have always preceded implementation of the same in
hardware…

//David

Thanks for your comments,

-Loren> On Wed, 19/06/2002 14:05:06 , Loren Osborn <@Loren_Osborn> wrote:


Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup

Well… Adding BlitBehind is certainly something
debatable. I felt it belonged there because it
reached into some low level SDL stuff… It could
certainly be implimented externally, but It would
probably need to be updated any time the SDL RLE or
alpha blitters change. My intent was to keep this in
SDL so that it could all stay in sync.

Yes, and I like the idea as well. It’s just that I’m not sure it’s possible to implement in any efficient way on top of say, OpenGL or Direct3D.

As far as “dual alpha channels”, this is already in
SDL… It just doesn’t behave as I believe it should.
The current behavior is it blits as if the dest is
opaque, but retains the dest’s alpha data. I don’t
think that this is the expected behavior

Ah, now I see what you’re getting at. However, what’s a sensible default behavior here?

IMHO, it would be combining the alpha channels so that blitting the result to the screen gives the same result as blitting the two source images to the screen, on top of each other.

There are probably other opinions - and OpenGL lets you pick from a number of combinations of source and dest blending “operators”.

Also, as far as I know, mixing surface alpha with
alpha channel with color-keys seems to not be
disallowed in the API, but I don’t think that the
behaviors are predictable, or at least what is
expected…

Predictable it is (in my experience, at least), but you’re right; it’s not really what one would expect.

How SHOULD SDL behave when it’s told to
set the surface alpha on an RGBA surface???

IMHO, it should multiply the alpha channel with the surface alpha (as OpenGL or GIMP would), but obviously, that’s going to be dog slow if you’re not careful with the implementation. (Which is, AFAIK, the reason why it’s not done currently.)

//David

.---------------------------------------
| David Olofson
| Programmer

david.olofson at reologica.se
Address:
REOLOGICA Instruments AB
Scheelev?gen 30
223 63 LUND
Sweden
---------------------------------------
Phone: 046-12 77 60
Fax: 046-12 50 57
Mobil:
E-mail: david.olofson at reologica.se
WWW: http://www.reologica.se

`-----> We Make Rheology RealOn Thu, 20/06/2002 13:02:54 , Loren Osborn <linux_dr at yahoo.com> wrote: