SSPR sandbox
According to the documentation, sspr is pretty self explanatory :
QUOTE
SSPR(SX, SY, SW, SH, DX, DY, [DW, DH], [FLIP_X], [FLIP_Y]]
Stretch a rectangle of the sprite sheet (sx, sy, sw, sh) to a destination rectangle on the screen (dx, dy, dw, dh). In both cases, the x and y values are coordinates (in pixels) of the rectangle's top left corner, with a width of w, h.
Colour 0 drawn as transparent by default (see PALT())
dw, dh defaults to sw, sh
When FLIP_X is TRUE, flip horizontally.
When FLIP_Y is TRUE, flip vertically.
END OF QUOTE
So I was pretty surprised to see an upside down sprite while debugging, when I knew I wasn't even using the flip parameters anywhere.
Things are pretty normal as long as the coordinates are in the 0-127 range and the sizes in the 1-128.
What happens otherwise is unclear, so I wrote this little test cart. (image in the sprite sheet by Freds72)
Conclusions :
Source :
SX and SY can be outside the 0-127 range without problem, pixels outside the sprite sheet are considered black/index zero.
SW and SH must both be in the 1-128 range. Otherwise nothing is drawn at all.
Destination :
DX and DY can be outside the 0-127 range without problem.
DW/DH can exceed 128 without problem and without extra CPU cost that seem roughly proportionnal to the actual pixel surface drawn to regardless of the declared destination size.
a width or height of 0 doesn't draw anything, as expected.
a negative width or height results in a mirrored image. It also affects where the image is placed :
if DH is negative and DW is positive, the image id flipped vertically and DX/DY are the coordinates of the lower left corner of the image instead of the usual top left.
DW negative and DH positive results in horizontal flip with coordintates indication lower right corner?
DW negative and DH negative results on flipped both horizontally and vertically, and the DC/DY indicate lower right corner
[Please log in to post a comment]
