<div dir="ltr"><div>Hmmm, okay, so how about if I implement this as a feature for all slice types,and call it something like sl->ScalePosition<br><br></div><div>Later on, when sl->ScaleSize becomes possible, we can add it then, defaulting it off. At that time we can also add the ability to set both ScalePosition and ScaleSize to the same value simultaneously using a convenience plotscripting command (and perhaps a convenience ui in the slice editor)<br>
<br></div><div>I do rather like the idea of using this feature for the walkabout layers on a map so we can support more walking speeds... although it does sound like a challenge to implement.<br><br>---<br></div><div>James<br>
</div><div><br><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 11, 2014 at 10:37 PM, Ralph Versteegen <span dir="ltr"><<a href="mailto:teeemcee@gmail.com" target="_blank">teeemcee@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Slices already transform all their children: they translate their<br>
positions and apply clipping. So the plan was not to have a separate<br>
ScaleSlice, but to allow all slices to scale and rotate their children<br>
(including their positions).<br>
<br>
It seems useful to have a "do not scale" bit on slices, which causes<br>
scaling transformations on ancestor slices to only affect position<br>
rather than scale, like ScrunchSlice. For example you could place some<br>
non-scaling icons on the map and then zoom out the map.<br>
<br>
Does ScrunchSlice have any uses aside from working around the lack of<br>
floating point support in scripts? I suppose my suggestion is to<br>
implement general scaling instead, but force all slices to have "do<br>
not scale" always on, until scaling of sprites and MapSlices is<br>
implemented. But maybe this will makes the implementation more<br>
difficult. Also long term I would want all slices to default to<br>
do-not-scale off.<br>
<br>
(And I think we need to allow subpixel placement of<br>
walkabouts/walkabout slices anyway, to allow a wide range of movement<br>
speeds at higher frame rates)<br>
<div><div class="h5"><br>
On 12 February 2014 18:04, James Paige <<a href="mailto:Bob@hamsterrepublic.com">Bob@hamsterrepublic.com</a>> wrote:<br>
> The other day we were talking in IRC a bit about fps, and I mentioned that I<br>
> had problems with my experiments at doubling the fps<br>
><br>
> When I double the fps, that screws up pixel-based movement speeds. For<br>
> example, in my sidescroller's scripting, there are many objects that move at<br>
> a speed of 3 pixels per tick, or 5 pixels per tick. If the fps is doubled,<br>
> the tick length is halved, and so to keep the movements the same, I have to<br>
> halve the movement speeds.<br>
><br>
> However, we can only have integers in plotscripting right now, so I can't do<br>
> speeds of 1.5 or 2.5<br>
><br>
> I got to thinking, and I imagined a ScruchSlice<br>
><br>
> The ScrunchSlice would be like a ContainerSlice, but it would have the added<br>
> property of modifier for x and y coordinates of its immediate children.<br>
><br>
> For example, if I made a ScrunchSlice with a modifier of 2, and set it to<br>
> fill the screen, it would behave as if it was 640x400 instead of 320x200.<br>
> This would (with appropriate scripting) be a way of easily simulating<br>
> sub-pixel resolution. The actual ScreenX and ScreenY of the child slices<br>
> would be rounded to the nearest pixel.<br>
><br>
> This would be very handy for my own game, but before I implement it as a<br>
> built-in feature I want to discuss it, because I would not want it to<br>
> interfere with any other plans.<br>
><br>
> I imagine that at some point in the future we might be fancy enough to have<br>
> a ScaleSlice that actually transforms not just the position, but also the<br>
> size of its children and grandchildren, so that is why I would name this<br>
> slice a ScrunchSlice, to make it clear that it is not a ScaleSlice<br>
><br>
> Does this sound crazy?<br>
><br>
> ---<br>
> James<br>
><br>
><br>
><br>
</div></div>> _______________________________________________<br>
> Ohrrpgce mailing list<br>
> <a href="mailto:ohrrpgce@lists.motherhamster.org">ohrrpgce@lists.motherhamster.org</a><br>
> <a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" target="_blank">http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org</a><br>
><br>
_______________________________________________<br>
Ohrrpgce mailing list<br>
<a href="mailto:ohrrpgce@lists.motherhamster.org">ohrrpgce@lists.motherhamster.org</a><br>
<a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" target="_blank">http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org</a><br>
</blockquote></div><br></div>