Rotate Shape - adds one pixel from left and top

[peceha]

Is that normal behavior (still blitz 2.1)?

I have a shape 16x16. After doing same rotation (0.25 or 0.5 or 0.75) my shape becomes 17x17 (checked with ShapeWidth/ShapeHeight).
The very first row and column is empty (background color) and the original shape (drawing) starts at 1,1

Thanks

[Daedalus]

Hmmm, I haven't noticed it myself - that's very odd. I'll check when I go home, it's possible that it has happened to me and I simply haven't noticed the graphics being a pixel out. But I would say it shouldn't happen. Perhaps it's a bug, or a floating point imprecision. Are you using a literal value in the code (Rotate 0, 0.25) or a variable (Rotate 0, MyAngle)?

[peceha]

This is the code (literal value for rotation):

WbToScreen 0
ShowScreen 0

BitMap 0,640,600,2
LoadBitMap 0,"ram:test.iff"

GetaShape 0,0,0,16,16

CopyShape 0,1
Rotate 1,0.25

CopyShape 0,2
Rotate 2,0.5

CopyShape 0,3
Rotate 3,0.75

Window 0,0,15,128,128,$2|$4|$8|$400|$1000,"my game",1,2

WBlit 0,0,0
WLocate 0,20
Print ShapeWidth(0)

WBlit 1,16,0
WLocate 16,20
Print ShapeWidth(1)

WBlit 2,32,0
WLocate 32,20
Print ShapeWidth(2)

WBlit 3,48,0
WLocate 48,20
Print ShapeWidth(3)

and this is the result. I'm not sure if you can see on the picture but second and third tiles from left are shifted by 1 px and their width is 17 (printed below). Original tile has left, top and right edge white

[Dunny]

I'm assuming this is rotated in degrees rather than radians?

If you rotate a bitmap through non-90 degree rotations, it will get bigger. That's just the way it is - it's either that or you lose pixels. Rounding errors means that sometimes you get empty space at the edges.

You can test that by rotating by 45 degrees and see what happens.

[peceha]

This is taken from manual:

The Rotate command allows you to rotate a shape object.
Angle Ratio specifies how much clockwise rotation to apply, and should be in the range zero to one. For instance, an Angle Ratio of .5 will cause a shape to be rotated 180 degrees, while an Angle Ratio of .25 will cause a shape to be rotated 90 degrees clockwise.

All the rotations that take place in a code are: 90 deg, 180 deg, 270 deg (0.25, 0.5, 0.75)

[Daedalus]

Hmmm, it seems there's something funky going on. I've used that command in a game to rotate a shape that's 20x9 in size. The sizes the shape ends up with the various rotations are:

0.25 (90 degrees): 21x9
0.5 (180 degrees): 10x21
0.75 (270 degrees): 20x10

So, while the pixels look fine on screen, it's adding an extra line in most cases. Not consistently in both directions with my shapes. I'm guessing it must be some sort of imprecision in the algorithm, which is probably fine when rotating an arbitrary angle, but for an exact 90, 180 or 270 rotation it's quite annoying. This is in Amiblitz 3 too, so it doesn't appear to have ever been fixed...

At least you know it's not you I would suggest doing the rotation in DPaint or PPaint instead if it turns out to be a critical issue, as it would be for a tile-based engine. Alternatively, you could write your own routines in Blitz - so long as they don't need to be time-critical, you could use a couple of for...next loops to do precise 90 degree rotations to a dummy bitmap.

[peceha]

Thanks for testing !! I was actually waiting for the results

I think I will choose the easy way (dPaint) - the number of tiles will increase a little bit.
Anyway XFlip and YFlip are working fine so I can still use them for 180 deg.

Thanks.