[Ohrrpgce] Slice Z idea

[James Paige]

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.

Possible alternative names:
W
upness
ana


*spissitude*
...I'm making this worse, aren't I?

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


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20170925/c15a606b/attachment.html>