Rotation + non-uniform Scaling Bitmap is cut off

I use transformedBitmap (from the C API) (SDK v1.4.0) to scale an image along one axis and rotate it. However it seems the output dimensions of the resulting image do not account for the image being scaled and rotated, so it is cut off.
Current Behaviour:
playdate-20211015-211000_BUG
Desired behaviour: I would like the transformed bitmap to completely contain my initial bitmap, and not cut it off.

Current workaround: scale and rotate in two separate calls to transformedBitmap.

2 Likes

Oof. I don't know how that slipped through. :frowning: When it computes the size of the resulting image it was as if it rotated first then scaled, but then it draws it (correctly) the other way around--scaled first then rotated. I've fixed that and I'm also adding pd->graphics->drawRotatedBitmap to the C API like Lua has, where you can draw the image directly with scaling and rotation instead of creating a new image. That might work better for you if you're updating that image frequently. If not, it's probably faster to do what you're doing now and avoid hitting that slow rotate/scale function every frame.

1 Like

oh, and just a heads up: I'm renaming transformedBitmap to rotatedBitmap in the next release, since that's what the equivalent Lua function is called.

A few times I've also wanted to draw rotated and faded (specifcally faded after rotation so the pattern isn't rotated oddly)... I don't know what this means, just that I have to create multiple images to do this. I can cache it (and do in some cases!). I wonder if a more dynamic draw function would be useful, something like draw(x, y, &props) where props is a struct of changes like flip, src_rect, opacity, fade algorithm, rotation, etc). This of course only makes sense if somehow a draw function could handle these options without creating copies of itself, so it's just one loop through the bitmap transforming the location and color of each pixel before drawing. Maybe?