[Ohrrpgce] ScrunchSlice idea

[Ralph Versteegen]

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.

> 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).

> ---
> 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
>