This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• proposed patch (v1) (2546_rotalpha_v1.diff, text/plain, 2015-06-20 00:52:12 +0000, 12496 bytes)
• proposed patch (v2) (2546_rotalpha_v2.diff, text/plain, 2015-06-20 02:17:29 +0000, 12344 bytes)

Reported in version: HG 2.0
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2012-07-20 13:26:50 +0000, Ellie wrote:

Calling SDL_RenderCopyEx with zero rotation does unexpected and odd things:

Expected results:

• calling SDL_RenderCopyEx with zero rotation and no flipping yields exactly the same result as SDL_RenderCopy (also at the same render speed! no rotation algorithm should be applied), including working 8bit alpha
• calling SDL_RenderCopyEx with zero rotation and flipping yields the same result as SDL_RenderCopy flipped (so with full 8bit alpha channel)

Actual results:

• non-rotated SDL_RenderCopyEx calls use 1-bit alpha only

There is no obvious reason why non-rotated renderings would need to be stripped down to 1bit alpha.

Rotation should remain as it is, but consider adding an optional switch/setting to use full 8bit alpha also when rotating (to have the app developer make the speed/quality decision for software rotations).

On 2012-07-24 05:56:57 +0000, Ellie wrote:

When thinking more about this, I realized my suggested fix would lead to objects rotating with constant speed to display with 8bit alpha for a tiny moment and otherwise with 1bit alpha, which probably looks a bit stupid and inconsistent.

Can we have a switch to turn 8bit alpha on for SDL_RenderCopyEx in software, no matter whether it is passed a 0 degree angle or not? Then application developers can fix this on their own in the most consistent, yet performance-conserving way.

(e.g. switching it off consistently for objects which are known to rotate, even if they might rest with 0 degree at some point, and switching it on for objects which are known to not rotate ever but which need to be flipped at some point - that is something which only the application can judge since that requires deeper knowledge about the logic of the rendered sprites)

On 2013-02-12 04:32:25 +0000, Ellie wrote:

May I bump this issue again? It would greatly improve render consistency if it was possible to have 8bit alpha with the software SDL_RenderCopyEx and rotation.

The 8bit alpha at angle 0 can be done by using SDL_RenderCopy for that case (which is what I do now), but for all other angles there would need to be actual support in SDL!

On 2013-02-12 23:35:18 +0000, Sam Lantinga wrote:

Sure, this sounds good. Do you have a patch in mind?

On 2013-02-22 18:45:01 +0000, Ellie wrote:

Sorry I don't :) I'm not even sure if SDL_gfx supported this (where the new software rotation code originates from I suppose?). I just thought I'd bring it up again since it kinda ruins the software mode for a small test game I did - but then again I don't rely much on a working software mode, it's just nice to have.

On 2013-02-22 19:44:16 +0000, Sam Lantinga wrote:

Maybe post on the mailing list and request one?

On 2014-05-14 20:58:37 +0000, Adam M. wrote:

I don't even think there should be a switch for 1-bit alpha. If the surface has an 8-bit alpha channel and is set to use alpha blending, the rendering should be done with 8-bit alpha, period. It's simply wrong to render a surface with an 8-bit alpha channel using only one bit of alpha. If the developer wants 1-bit alpha, let him convert the surface to a format with a 1-bit alpha channel, or use a color key.

I do agree that calling SDL_RenderCopyEx with zero rotation should use the faster no-rotation algorithm, if it doesn't.

On 2014-05-15 12:59:38 +0000, Gabriel Jacobo wrote:

*** Bug 2546 has been marked as a duplicate of this bug. ***

On 2014-05-15 18:49:27 +0000, Adam M. wrote:

This also happens with SDL_RenderCopy (which does not support flipping or rotation), as described in bug # 2546. I'm not sure if they have the exact same cause, but since # 2546 has been marked as a duplicate of this one, I hope both problems are fixed here.

On 2015-06-20 00:39:31 +0000, Adam M. wrote:

There are three problems in the code that I see.

1. SW_RenderCopyEx enables a color key on surface_scaled even if the source surface didn't have a color key.
2. SW_RenderCopyEx doesn't copy blend mode, color mod, or alpha mod from src to surface_scaled.
3. When SDL_BlitScaled(src, srcrect, surface_scaled, &tmp_rect) is called, it blends the src pixels into surface_scaled instead of overwriting them (if src has blending, etc. enabled).

On 2015-06-20 00:52:12 +0000, Adam M. wrote:

Created attachment 2191
proposed patch (v1)

I've attached a patch that 1) fixes the three problems that I mentioned, 2) adds the requested performance improvement of using the regular blit function if no rotation or flipping is needed, 3) avoids cloning the source surface if no stretching is required, and 4) fixes an apparent off-by-one error in the 32-bit rotation code, and 5) simplifies the rotation code slightly.

I think this is a complete fix for all the issues in this bug. Please test it.

On 2015-06-20 02:17:29 +0000, Adam M. wrote:

Created attachment 2194
proposed patch (v2)

I reverted the off-by-one "fix" because it was erroneous.

On 2015-06-20 06:21:09 +0000, Sam Lantinga wrote:

Fixed, thanks!
https://hg.libsdl.org/SDL/rev/5c4a85c5b648

On 2015-06-20 07:35:52 +0000, Adam M. wrote:

There actually /is/ an off-by-one error in the smooth rotation code, by the way. But I can see that it's deliberate (perhaps due to laziness or concern about performance).

I'll probably submit another patch to fix that tomorrow.

On 2015-06-28 22:35:04 +0000, Adam M. wrote:

(That's bug # 3029.)