<div dir="ltr"><div dir="ltr">That is all very interesting!</div><div dir="ltr"><br></div><div dir="ltr">> Right now, rotating around a custom offset and specialising<br>
> SliceX/YAnchor() to compensate for that offset + rotation angle seems<br>
> preferable. Funny, I almost got rid of those functions a couple weeks<br>> ago because they seemed unneeded.</div><div dir="ltr"><br></div><div>I think I agree with your conclusions here, although some of this is over my head, and I don't understand all the issues 100%</div><div><br></div><div>---</div><div>James Paige<br><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 22, 2019 at 5:51 PM Ralph Versteegen <<a href="mailto:teeemcee@gmail.com">teeemcee@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I've added a rotozoomer and slice rotate/zoom options, though there<br>
are various things that need to be addressed before I expose it to<br>
users. And those are mostly to do with slice positioning. This email<br>
is about that, and not anything interesting.<br>
<br>
It's natural that changing the size of a sprite slice should stretch<br>
its sprite to match its width and height, just like lines, rects and<br>
ellipses.<br>
The hidden "scaled" sprite slice setting (a bool), only available in<br>
32-bit color mode, already acts like this. (I'll be getting rid of<br>
this now-redundant setting).<br>
Sprite slices could still have zoom/zoom x/zoom y properties, but they<br>
could just provide an alternative way to set the size of the slice.<br>
(But sub-pixel zoom is a nice thing to have, so I'll probably still<br>
store the zoom separately. I need to modify the rotozoomer to support<br>
this.)<br>
We will need a backcompat bit to enable zooming, because you can<br>
already change the width and height of a sprite by setting it to fill,<br>
but it does nothing. (Even though "set slice width/height" is<br>
disallowed, Fill Parent is a loophole)<br>
<br>
That's all fine, but rotation is a problem. As they rotate, the size<br>
of the axis-aligned bounding box changes. But if you want to set both<br>
the sprite size and rotation, the slice width and height should be the<br>
non-rotated size, not the bounding box size.<br>
<br>
But if bounding box is used for positioning/alignment, it would mean<br>
their position can't be calculated like other slices.<br>
And how should child slices of the sprite be positioned, how should<br>
the Fill Parent setting for both the sprite and its children work,<br>
"Cover Children", "slice at pixel", and whatever else I've forgotten?<br>
<br>
In a perfect world, perhaps all children of a rotated sprites would be<br>
rotated too, like an OpenGL transformation matrix stack... but we<br>
wouldn't really expect child slices of a stretched sprite to be<br>
stretched in the same way. I think that if we ever implemented<br>
whole-slice-tree zooming/rotating, they should actually be completely<br>
separate slice properties, not sprite properties. Still, even if the<br>
child slices aren't rotated, maybe the alignment points on the rotated<br>
parent should be rotated too, for convenience when positioning? Oh,<br>
but then child X and Y offsets would also have to be rotated for<br>
consistency. How about we assume that in future we would add separate<br>
settings to rotate and stretch a slice tree, so anything we add now<br>
should be orthogonal to that instead of overlapping: we shouldn't add<br>
transformation of child positions now, because there's a better way to<br>
do it later.<br>
<br>
Still, that leaves the problem that the bounding box size is not equal<br>
to the "specified size" set in the slice editor/by scripts.<br>
If rotated sprites always rotated around their center and we treated<br>
the bounding box size as being equal to the specified size, even<br>
though the drawn sprite might extend far outside it, then all the<br>
problems can go away. "slice at pixel" could always be given special<br>
cases for rotated sprites, ellipses, and lines anyway.<br>
<br>
But you should be able to customise the point around which a sprite is<br>
rotated, otherwise correctly positioning a sprite rotated around a<br>
corner (eg a swung weapon) would require complicated calculations by<br>
the user.<br>
At a minimum sprites should rotate around their anchor point, but even<br>
that's not flexible enough - for a weapon swung in an arc the point<br>
should actually be outside the sprite. You could add blank space to<br>
the sprite, though.<br>
Again, if the bounding box size and position didn't change at all<br>
there would be no problem, except the sprite is likely to be<br>
completely outside its bounding box! That seems a tad ridiculous. If<br>
the box size didn't change but the position did that seems reasonable<br>
enough, and only the calculation of the anchor point would need to be<br>
specialised. Allowing the size to change requires replacing most<br>
occurrences of sl->Width and sl->Height in the code!<br>
<br>
Another example: a ball rolling along the top of a surface. You might<br>
want its anchor point to be the bottom of the slice, but to rotate<br>
around the center.<br>
<br>
Right now, rotating around a custom offset and specialising<br>
SliceX/YAnchor() to compensate for that offset + rotation angle seems<br>
preferable. Funny, I almost got rid of those functions a couple weeks<br>
ago because they seemed unneeded.<br>
_______________________________________________<br>
Ohrrpgce mailing list<br>
<a href="mailto:ohrrpgce@lists.motherhamster.org" target="_blank">ohrrpgce@lists.motherhamster.org</a><br>
<a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" rel="noreferrer" target="_blank">http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org</a><br>
</blockquote></div></div>