drawRotatedBitmap Draws from wrong center if degrees is one of the four cardinal directions

[cwm (Chris)]

This is on the Windows C SDK / Simulator FWIW. I don't have a device to test on.

With a call like: pd->graphics->drawRotatedBitmap(bmp, x,y, 270, 0,0, 1,1) bmp will be drawn oriented as expected but not positioned relative to the 0,0 center. Instead, it is drawn with it's top/left at the unrotated coords. Same thing happens at 90 and 180 degrees.

For any angle in between, the bitmap is drawn as expected: rotated around the provided center.

Corollary to this: if you gradually increase degrees by 1 with a center of 0.5f 0.5f, the rotation will glitch or skip as it crosses the cardinal directions.

As seen here, the fourth draw is in the wrong place:

[zbauermeister (Zac Bauermeister)]

I also see this behavior with image:drawRotated(), but (at least as far as I can tell) only if the source image has transparency on some edges for some reason.

[samdze (Samuele Zolfanelli)]

I'm also experiencing this issue, drawRotatedBitmap draws a misplaced bitmap when it is given a multiple of 90 degrees angle (also negative).

Tested on the simulator on macOS.

[dave (Dave Hayden)]

I've got a fix in the queue now. Sorry it took me so long!

[redshift (Tom)]

Thanks Dave! This was mystifying. Hopefully it can come in a release soon.

[Eiyeron]

Hello. I'm still having this issue in the SDK 2.0 and reproduced it on hardware on OS 2.00, the exact mis-pivoting on 90° and 180°. I see that happening on a sprite that has a relative center of (0.5, something).

I have a workaround where I'm checking the rounded angle (with roundf) if it's a multiple of 90 and 180. If it is, I'm flipping the y-axis pivot to make up (so 1.f - center_y). Somehow, it works, even if it's a bit jumpy.

Here's a part of my code (with variables renamed) to show what I did to circumvent the weird pivot swap.

    int integer_angle = ((int)roundf(crank_angle) % 360;
    if (integer_angle == 90 || integer_angle == 180)
    {
        pd->graphics->drawRotatedBitmap(
            my_bitmap,
            x, y,
            integer_angle,
            0.5f, 1.f - center_y,
            1.f, 1.f);
    }
    else
    {
        pd->graphics->drawRotatedBitmap(
            my_bitmap,
            x, y,
            crank_angle,
            0.5f, center_y,
            1.f, 1.f);
    }

I'm using roundf in the code because a simple truncation would miss angles like 89.98f or whatever which still triggered the issue. I'm not sure if it fixes it for angles that would be rounded back to 91.f or 181.f.

Note for future readers : I haven't checked if you'd need to flip both center's coordinates if the rotation angle ends in the glitching angles.

[MrBZapp]

I just ran across this bug in v2.1.1 while trying to use a single image of a flower petal rotated to draw a blooming flower, and wanted to add my voice to the choir.

I've only tried a 0.0f centery, and like Eiyeron, I am only seeing it at 90 and 180 degrees. 270 and 360 are fine. Special case-ing the wonky angles by inverting the centery from 0 to 1 alleviates the problem:

// C++ API bindings are calling `drawRotatedBitmap` from the C API under the hood.
petal.draw(bounds.getCenter().toInt(), 0.0f, 0.5f, 0.0f);
petal.draw(bounds.getCenter().toInt(), 45.0f, 0.5f, 0.0f);
petal.draw(bounds.getCenter().toInt(), 90.0f, 0.5f, 1.0f);  // Whoops!
petal.draw(bounds.getCenter().toInt(), 135.0f, 0.5f, 0.0f);
petal.draw(bounds.getCenter().toInt(), 180.0f, 0.5f, 1.0f); // Whoops!
petal.draw(bounds.getCenter().toInt(), 225.0f, 0.5f, 0.0f);
petal.draw(bounds.getCenter().toInt(), 270.0f, 0.5f, 0.0f);
petal.draw(bounds.getCenter().toInt(), 325.0f, 0.5f, 0.0f);
petal.draw(bounds.getCenter().toInt(), 360.0f, 0.5f, 0.0f);

Produces:

without special casing the same code produces this:

Out of curiosity I tried centery offsets of 0.9f, and 0.1f, both of which exhibit the same inversion behavior. I haven't bothered trying anything with centerx.