[Ohrrpgce] ScrunchSlice idea

Wed Feb 12 07:36:34 PST 2014

On Wed, Feb 12, 2014 at 7:26 AM, Ralph Versteegen <teeemcee at gmail.com>wrote:

> On 13 February 2014 04:10, James Paige <Bob at hamsterrepublic.com> wrote:
> > 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)
>
> So would ScalePosition only apply to the immediate children or to all
> descendents? Proper scaling would apply to a whole slice subtree, but
> I assume that you probably only want to affect the children.
>
> So it sounds like ScaleSize wouldn't really be complementary to
> ScalePosition. So I've changed my mind and now I think having a
> separate ScrunchSlice is better. If it eventually becomes
> obsolete/redundant to future features that is fine; it's better to
> have an obsolete slice type than to complicate the way other slices
> work.
>

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.

> > 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.
>
> I wasn't actually suggesting that: I think that's best implemented
> either with real factional slice positions (and there actually no need
> to wait for floating point support in HS for that), or just making
> NPCInst.x/y floats. (I don't really like that NPC and hero position
> are stored in two redundant places and one doesn't affect the other,
> but that's a story for another day).
>

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)

When you talk about redundant storage of position, you mean that it is
stored both in NPCinst and in the NPC slices?

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.

---
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
> >
> >
> >
> > _______________________________________________
> > 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/cec5f89c/attachment-0002.htm>