[Ohrrpgce] SVN: teeemcee/11072 Disallow resizing Sprite slices/Sprite sizes now reset to match Frame si

James Paige Bob at hamsterrepublic.com
Sat Mar 30 09:41:40 PDT 2019


This all sounds good to me.
I don't expect any breakage in any of my own scripts, since any time I want
a Sprite to have a hitbox that differs from its actual shape, I always use
a Sprite component attached to a container slice, very much like the way
NPCs work

On Saturday, March 30, 2019, <subversion at hamsterrepublic.com> wrote:

> teeemcee
> 2019-03-29 23:06:51 -0700 (Fri, 29 Mar 2019)
> 1865
> Disallow resizing Sprite slices/Sprite sizes now reset to match Frame size.
>
> (Actually, Sprite slices can still be resized by setting them to Fill
> Parent/
> Cover Children in the slice editor.)
>
> This fixes sprite slices not updating after a spriteset is resized, causing
> e.g. walkabouts to be misdrawn.
>
> Resizing Sprite slices using "set slice width/height" and even using "fill
> parent" on a Sprite slice has been disabled for years, but not always.
>
> r10487 (8 months ago) additionally reset sprite sizes when a collection is
> loaded or a sprite modified. That was necessary in order to fix a lot of
> brokenness when non-standard-sized sprites are used (e.g. a sprite size
> changed
> after a slice collection was edited)
>
> This commit now also disallows changing size of a Sprite in the slice
> editor.
>
> All of these were backcompat breaks, but it's difficult to avoid, and
> allowing
> sprites to be resized was always a mistake.
> When you load a collection there's no way to tell whether a sprite has the
> wrong size because the user overrode it, or because the spriteset has since
> been resized. So if we did want to avoid a backcompat break it would have
> to be
> by checking whether an .rpg is older than when spriteset resizing was
> implemented, and toggle a backcompat bit based on that. However I think
> it's
> unlikely that anyone actually relied on overriding the size of a sprite
> slice,
> so I'm not going to add a backcompat bit until I hear it's needed.
> On the other hand, setting a Sprite slice to Fill Parent is much more
> common,
> I think some games do rely on that. In future I will be getting rid
>
> Note, in future, you'll be able to zoom a sprite slice by changing its
> size. I
> will add a backcompat bit to enable that - toggling whether Fill Parent on
> a
> Sprite causes it stretch or not. (Or maybe the bit will toggle whether you
> can
> zoom sprite slices by changing their size)
> ---
> U   wip/sliceedit.bas
> U   wip/slices.bas
> U   wip/whatsnew.txt
> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20190330/4911ff8a/attachment.html>


More information about the Ohrrpgce mailing list