[Ohrrpgce] ScrunchSlice idea

Wed Feb 12 08:19:44 PST 2014

On 13 February 2014 04:36, James Paige <Bob at hamsterrepublic.com> wrote:
> 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)

Ah, I'd forgotten about that. Yes, rounding error is bad, we wouldn't
really want positions like x=40.0000002, which would break checks for
x == 40

Wait actually, come to think of it all existing script commands need
to continue to return integers, otherwise results will be different
when dividing. Hmm, that's pretty unfortunate: you would be able to
set the position of something to a fractional, but not read it back. I
certainly don't want to add alternatives to lots of commands with
different return types. Returning a float only if the value isn't an
integer is one option, but that may be error prone as you would have
to manually cast to float or int if that's what you want. Maybe a
backcompat global bitset "Positions are floating point values".

Of course for movement we really only need/want to support "x pixels
per y ticks" where x and y are integers (ie rational) movement speeds.
Using rational numbers seems like much more trouble.

What we could do is round positions every frame (rather than at the
end of every one tile movement) to an integer number of pixels, but
only if it's close to an integer already. So 40.000002 gets rounded to
40, but 40.05 doesn't.

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

That's an interesting idea, but I thought the idea was to move to
storing all slice positions as floats so that movement can be smoothly
interpolated. Of course we would always round to an integer pixel
position at least for sprites.

> ---
> 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
>
>
>
> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>