We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 3029 - software renderer cuts off edges when rotate-blitting with a multiple of 90 degrees
Summary: software renderer cuts off edges when rotate-blitting with a multiple of 90 d...
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: render (show other bugs)
Version: 2.0.3
Hardware: x86_64 Windows 7
: P2 normal
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-06-20 17:43 UTC by Adam M.
Modified: 2016-10-08 01:00 UTC (History)
1 user (show)

See Also:

Attachments
proposed patch (v1) (9.75 KB, patch)
2015-06-20 17:48 UTC, Adam M. 		Details | Diff
proposed patch (v2) (9.78 KB, patch)
2015-06-20 18:08 UTC, Adam M. 		Details | Diff
Show Obsolete (1) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Adam M. 2015-06-20 17:43:50 UTC 
When doing a rotated texture copy with the software renderer, where the angle is a multiple of 90 degrees, one or two edges of the image get cut off. This is because of the following line in sw_rotate.c:
    if ((unsigned)dx < (unsigned)sw && (unsigned)dy < (unsigned)sh) {
which is effectively saying:
    if (dx >= 0 && dx < src->w-1 && dy >= 0 && dy < src->h-1) {

As a result, it doesn't process pixels in the right column or bottom row of the source image (except when they're accessed as part of the bilinear filtering for nearby pixels). This causes it to look like the edges are cut off, and it's especially obvious with an exact multiple of 90 degrees.
Comment 1 Adam M. 2015-06-20 17:47:14 UTC 
Additionally, rotations by a multiple of 90 degrees (which is probably a much more common case than arbitrary rotation) can be done significantly faster than the current rotozoomer method. Since fixing the rotozoomer is a bit tricky, I'd rather just implement a fast path for these rotations that fixes the edge-clipping at the same time.
Comment 2 Adam M. 2015-06-20 17:48:05 UTC 
Created attachment 2197 [details]
proposed patch (v1)

I've proposed a patch to fix this problem.
Comment 3 Adam M. 2015-06-20 17:59:44 UTC 
Don't apply this yet. There is a problem in the case of a 270 degree rotation when the rotation point is not the center.
Comment 4 Adam M. 2015-06-20 18:08:56 UTC 
Created attachment 2198 [details]
proposed patch (v2)

Darn typos. Fixed patch attached.
Comment 5 Adam M. 2015-06-28 22:57:45 UTC 
If you want to reproduce this for yourself, create a surface containing a hollow rectangle of the same size as the surface. Then, attempt to do a rotate-blit with a rotation of 90 degrees. If the software renderer takes the anti-aliased path in the rotation code, two edges of the rectangle will be cut off.
Comment 6 Sam Lantinga 2016-10-08 01:00:53 UTC 
Fixed, thanks!
https://hg.libsdl.org/SDL/rev/1e1ce9f6d215