[Ohrrpgce] Slice Z idea

Tue Sep 26 08:42:41 PDT 2017

In IRC, SDHawk mentioned that he'd come up with a different solution to the
same problem in his engine: He uses two different trees for his equivalents
of slices (which borrow some ideas from the OHR): one determines positions
(and transformation matrices), and the other determines draw order. So each
slice appears in both trees, and by default they have the same parent in
both. So it's quite similar to our slice attachment, but cleaner. He came
up with the idea himself, never heard of anyone else using it.
He said he's hardly made use of it yet, but mainly for UI things attached
to the map, like the 'cursor above an NPC' example.

I don't think there's considerable difference in the utility of the two
approaches. You could use autosort on siblings in the draw-order tree to
get similar behaviour as Z depth. But two trees sounds more complicated:
how do you delete a slice?

On 26 September 2017 at 04:23, Ralph Versteegen <teeemcee at gmail.com> wrote:

>
>
> 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/20170927/20eacdea/attachment.html>