[Ohrrpgce] ScrunchSlice idea

[James Paige]

Hmmm, okay, so how about if I implement this as a feature for all slice
types,and call it something like sl->ScalePosition

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)

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.

---
James




On Tue, Feb 11, 2014 at 10:37 PM, Ralph Versteegen <teeemcee at gmail.com>wrote:

> 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
> >
> _______________________________________________
> 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/20140212/4a064f13/attachment-0002.htm>