<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Feb 12, 2014 at 7:26 AM, 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"><div class="">On 13 February 2014 04:10, James Paige <<a href="mailto:Bob@hamsterrepublic.com">Bob@hamsterrepublic.com</a>> wrote:<br>

> Hmmm, okay, so how about if I implement this as a feature for all slice<br>
> types,and call it something like sl->ScalePosition<br>
><br>
> Later on, when sl->ScaleSize becomes possible, we can add it then,<br>
> defaulting it off. At that time we can also add the ability to set both<br>
> ScalePosition and ScaleSize to the same value simultaneously using a<br>
> convenience plotscripting command (and perhaps a convenience ui in the slice<br>
> editor)<br>
<br>
</div>So would ScalePosition only apply to the immediate children or to all<br>
descendents? Proper scaling would apply to a whole slice subtree, but<br>
I assume that you probably only want to affect the children.<br>
<br>
So it sounds like ScaleSize wouldn't really be complementary to<br>
ScalePosition. So I've changed my mind and now I think having a<br>
separate ScrunchSlice is better. If it eventually becomes<br>
obsolete/redundant to future features that is fine; it's better to<br>
have an obsolete slice type than to complicate the way other slices<br>
work.<br><div class=""></div></blockquote><div><br></div><div>Oh, good point! I had not thought about the difference between grandchildren. Yes, I would only want it to scale child but not grandchild position, so I guess ScrunchSlice is the way to go after all.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
> I do rather like the idea of using this feature for the walkabout layers on<br>
> a map so we can support more walking speeds... although it does sound like a<br>
> challenge to implement.<br>
<br>
</div>I wasn't actually suggesting that: I think that's best implemented<br>
either with real factional slice positions (and there actually no need<br>
to wait for floating point support in HS for that), or just making<br>
NPCInst.x/y floats. (I don't really like that NPC and hero position<br>
are stored in two redundant places and one doesn't affect the other,<br>
but that's a story for another day).<br>
</blockquote><div><br></div><div>Ah, interesting. So if we do floats for NPCinst x and y would that require some extra code to enforce tile alignment at the end of each step (which still sounds like less work than using a ScrunchSlice) <br>
</div><div> <br></div><div>When you talk about redundant storage of position, you mean that it is stored both in NPCinst and in the NPC slices?<br><br></div><div>It seems like that could actually be a good thing. NPCinst to store the "real" position with subpixel resolution, and the NPC slice position to store the "rounded" position for display.<br>
<br>---<br></div><div>James<br></div><br><br><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
><br>
> On Tue, Feb 11, 2014 at 10:37 PM, Ralph Versteegen <<a href="mailto:teeemcee@gmail.com">teeemcee@gmail.com</a>><br>
> wrote:<br>
>><br>
>> 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>
>><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<br>
>> > 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<br>
>> > move at<br>
>> > a speed of 3 pixels per tick, or 5 pixels per tick. If the fps is<br>
>> > doubled,<br>
>> > the tick length is halved, and so to keep the movements the same, I have<br>
>> > to<br>
>> > halve the movement speeds.<br>
>> ><br>
>> > However, we can only have integers in plotscripting right now, so I<br>
>> > 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<br>
>> > 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<br>
>> > to<br>
>> > fill the screen, it would behave as if it was 640x400 instead of<br>
>> > 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<br>
>> > have<br>
>> > a ScaleSlice that actually transforms not just the position, but also<br>
>> > 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>
>> > _______________________________________________<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>
><br>
><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>
><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>
</div></div></blockquote></div><br></div></div>