[Ohrrpgce] ScrunchSlice idea

[Ralph Versteegen]

Slices already transform all their children: they translate their
positions and apply clipping. So the plan was not to have a separate
ScaleSlice, but to allow all slices to scale and rotate their children
(including their positions).

It seems useful to have a "do not scale" bit on slices, which causes
scaling transformations on ancestor slices to only affect position
rather than scale, like ScrunchSlice. For example you could place some
non-scaling icons on the map and then zoom out the map.

Does ScrunchSlice have any uses aside from working around the lack of
floating point support in scripts? I suppose my suggestion is to
implement general scaling instead, but force all slices to have "do
not scale" always on, until scaling of sprites and MapSlices is
implemented. But maybe this will makes the implementation more
difficult. Also long term I would want all slices to default to
do-not-scale off.

(And I think we need to allow subpixel placement of
walkabouts/walkabout slices anyway, to allow a wide range of movement
speeds at higher frame rates)

On 12 February 2014 18:04, James Paige <Bob at hamsterrepublic.com> wrote:
> The other day we were talking in IRC a bit about fps, and I mentioned that I
> had problems with my experiments at doubling the fps
>
> When I double the fps, that screws up pixel-based movement speeds. For
> example, in my sidescroller's scripting, there are many objects that move at
> a speed of 3 pixels per tick, or 5 pixels per tick. If the fps is doubled,
> the tick length is halved, and so to keep the movements the same, I have to
> halve the movement speeds.
>
> However, we can only have integers in plotscripting right now, so I can't do
> speeds of 1.5 or 2.5
>
> I got to thinking, and I imagined a ScruchSlice
>
> The ScrunchSlice would be like a ContainerSlice, but it would have the added
> property of modifier for x and y coordinates of its immediate children.
>
> For example, if I made a ScrunchSlice with a modifier of 2, and set it to
> fill the screen, it would behave as if it was 640x400 instead of 320x200.
> This would (with appropriate scripting) be a way of easily simulating
> sub-pixel resolution. The actual ScreenX and ScreenY of the child slices
> would be rounded to the nearest pixel.
>
> This would be very handy for my own game, but before I implement it as a
> built-in feature I want to discuss it, because I would not want it to
> interfere with any other plans.
>
> I imagine that at some point in the future we might be fancy enough to have
> a ScaleSlice that actually transforms not just the position, but also the
> size of its children and grandchildren, so that is why I would name this
> slice a ScrunchSlice, to make it clear that it is not a ScaleSlice
>
> Does this sound crazy?
>
> ---
> James
>
>
>
> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>