[Ohrrpgce] Slice Z idea

[Ralph Versteegen]

On 26 September 2017 at 04:00, James Paige <Bob at hamsterrepublic.com> wrote:

> I am cool with removal of the "Attach" feature. I had actually forgotten
> that we had not already removed it.
>
> I am cautiously optimistic that your "Z" idea is a good one, although lets
> name it something else. It's clash with the other meaning of hero z and npc
> z is too big to even appeal to my own love of confusing naming schemes.
>

Usually I would try to come up with some convoluted scheme to allow
combining them somehow, but I have a feeling that in this case, that just
isn't going to work.


>
> Possible alternative names:
> W
> upness
> ana
>
>
> *spissitude*
> ...I'm making this worse, aren't I?
>
It might not be necessary to obfuscate the similarity with Z ;)


>
> I can totally live with z if we can't come up with anything better. ;)
>
> On the plus side, I think I now have a front-runner for the "s" release
> codename
>

I'm glad that's worked out, deciding codenames by committee is hard work!

>
>
> On Mon, Sep 25, 2017 at 6:51 AM, Ralph Versteegen <teeemcee at gmail.com>
> wrote:
>
>>
>> ---- About Slice.Attach and why it might be time to delete it ----
>>
>> So we have this slice 'attach' feature that isn't exposed or used at all.
>> It could be used to decouple when a slice is drawn and where it's drawn:
>> attaching 'sl'
>> to a slice 'attch' mean's sl's screen position (and size when filling,
>> but that's useless) is computed
>> relative to att instead of it's parent.
>> So:
>>   Owned by: parent
>>   Position: attach-slice if any, otherwise parent
>>   Draw order: parent
>>
>> Possible use case: you want a bobbing cursor to display above an NPC, and
>> want it to appear above
>> everything else on the map. You could parent that cursor to the script
>> layer (above the map)
>> and attach it to the npc slice.
>>
>> But I think the way attach works isn't that useful for this sort of thing.
>> Plus would need to add a refcount system to slices in order to handle
>> deleted slices with
>> stuff attached to them! And we would have problems with loops making
>> screen positions incomputable,
>> and saving to file. And don't you want the cursor to be deleted when the
>> NPC is?
>>
>> ---- About a new slice Z-index feature that could be cool and easy ----
>>
>> So, inspired by HTML element's z-index:
>> What if you could instead parent the cursor to the NPC slice, and make it
>> appear above everything else?
>> By adding a 'Z' property to slices, with higher Z drawn on top. This
>> isn't the same thing as autosort,
>> because Z could change when a slice is drawn to some other point.
>> Note: this Z is quite different from hero/NPC Z. Unfortunate name clash.
>>
>> Suppose we limit each slice's Z to be zero or greater, and each slice's
>> total Z is equal to
>> sum of all its ancestors.
>> Then it turns out it's actually very easy to implement this: while
>> drawing, every time you
>> encounter a slice with nonzero Z just put it on a queue and delay drawing
>> it until later.
>> (If we allowed negative Z then we would have to instead first put all
>> visible slices in a list
>> (or just those with nonzero Z) and sort them by Z. Also easy, though a
>> lot slower if
>> slices don't have zero z by default, but I think it would be still be
>> neglible.)
>>
>> Now:
>>   Owned by: parent
>>   Position: parent
>>   Draw order: z value primarily, parent secondarily
>>
>> Since this appears to be really easy to implement, I feel like doing so,
>> and working out
>> what the uses of it would be later ;)
>>
>> ---- Brainstorming for what you could use it for ----
>>
>> An example use would be allowing NPCs to appear on other map layers (if
>> we didn't simply
>> make a change to allow reparenting them to other map layers, which we
>> should definitely do anyway).
>> Map layers and other special layers could by default have z=100, z=200,
>> etc, (customisable).
>> (NOTE: for backcompat, we would need to give z values to everything
>> parented directly to
>> the root or map root, equal to the z value of its previous sibling. No
>> big deal.)
>>
>> You could throw a projectile in an arc and make it appear over the
>> overhead tree foilage map layer
>> while it's high enough.
>>
>> You can make sure objects (slices) on the ground that can be stepped on
>> always appear below
>> all npcs, without resorting to a hack like an extra layer for them
>>
>> Building on that, you could give NPCs solid black shadows which don't
>> cover up any
>> objects sitting on the ground (which are drawn below the feet of the NPCs
>> and can be
>> stepped on): parent the shadows ellipses to the NPC slice with Z=0, give
>> the NPC sprites
>> Z=2, and give any object slices parented to the map layer Z=1.
>>
>> You could have an NPC standing in water, with their feet appearing below
>> the water
>> surface and things floating in it (a map layer), by splitting the npc
>> sprite into two
>> pieces (bottom and top) with different Z. If you did this without slice
>> Z, you would have
>> to use slices and autosort for the water surface instead of a map layer,
>> and those slices
>> would suddenly snap from above the NPC to behind, which would look really
>> bad unless that
>> slice is just a few pixels high.
>>
>>
>> _______________________________________________
>> 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/20170926/02fec080/attachment-0001.html>