[Ohrrpgce] Slice Z idea

[Ralph Versteegen]

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