<div dir="ltr"><div>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.<br></div><div>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.</div><div><br></div><div><div><div class="gmail_extra"></div><div class="gmail_extra">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?<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 26 September 2017 at 04:23, Ralph Versteegen <span dir="ltr"><<a href="mailto:teeemcee@gmail.com" target="_blank">teeemcee@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="gmail-">On 26 September 2017 at 04:00, James Paige <span dir="ltr"><<a href="mailto:Bob@hamsterrepublic.com" target="_blank">Bob@hamsterrepublic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div>I am cool with removal of the "Attach" feature. I had actually forgotten that we had not already removed it.<br><br></div>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.<br></div></div></div></div></div></div></div></blockquote><div> </div></span><div>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.<br></div><span class="gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><br></div>Possible alternative names:<br></div>W</div><div>upness<br></div>ana<br><i>spissitude<br><br></i></div>...I'm making this worse, aren't I?<i><br></i></div></div></div></blockquote></span><div>It might not be necessary to obfuscate the similarity with Z ;)<br></div><span class="gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><i><br></i></div>I can totally live with z if we can't come up with anything better. ;)<br><br></div>On the plus side, I think I now have a front-runner for the "s" release codename<br></div></blockquote><div><br></div></span><div>I'm glad that's worked out, deciding codenames by committee is hard work! <br></div><div><div class="gmail-h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><i></i><br><div><div><div><div><div><div><div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="gmail-m_-2192307024014989478h5">On Mon, Sep 25, 2017 at 6:51 AM, Ralph Versteegen <span dir="ltr"><<a href="mailto:teeemcee@gmail.com" target="_blank">teeemcee@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="gmail-m_-2192307024014989478h5"><div dir="ltr"><br>---- About Slice.Attach and why it might be time to delete it ----<br><br>So we have this slice 'attach' feature that isn't exposed or used at all.<br>It could be used to decouple when a slice is drawn and where it's drawn: attaching 'sl'<br>to a slice 'attch' mean's sl's screen position (and size when filling, but that's useless) is computed<br>relative to att instead of it's parent.<br>So:<br>  Owned by: parent<br>  Position: attach-slice if any, otherwise parent<br>  Draw order: parent<br><br>Possible use case: you want a bobbing cursor to display above an NPC, and want it to appear above<br>everything else on the map. You could parent that cursor to the script layer (above the map)<br>and attach it to the npc slice.<br><br>But I think the way attach works isn't that useful for this sort of thing.<br>Plus would need to add a refcount system to slices in order to handle deleted slices with<br>stuff attached to them! And we would have problems with loops making screen positions incomputable,<br>and saving to file. And don't you want the cursor to be deleted when the NPC is?<br><br>---- About a new slice Z-index feature that could be cool and easy ----<br><br>So, inspired by HTML element's z-index:<br>What if you could instead parent the cursor to the NPC slice, and make it appear above everything else?<br>By adding a 'Z' property to slices, with higher Z drawn on top. This isn't the same thing as autosort,<br>because Z could change when a slice is drawn to some other point.<br>Note: this Z is quite different from hero/NPC Z. Unfortunate name clash.<br><br>Suppose we limit each slice's Z to be zero or greater, and each slice's total Z is equal to<br>sum of all its ancestors.<br>Then it turns out it's actually very easy to implement this: while drawing, every time you<br>encounter a slice with nonzero Z just put it on a queue and delay drawing it until later.<br>(If we allowed negative Z then we would have to instead first put all visible slices in a list<br>(or just those with nonzero Z) and sort them by Z. Also easy, though a lot slower if<br>slices don't have zero z by default, but I think it would be still be neglible.)<br><br>Now:<br>  Owned by: parent<br>  Position: parent<br>  Draw order: z value primarily, parent secondarily<br><br>Since this appears to be really easy to implement, I feel like doing so, and working out<br>what the uses of it would be later ;) <br><br>---- Brainstorming for what you could use it for ----<br><br>An example use would be allowing NPCs to appear on other map layers (if we didn't simply<br>make a change to allow reparenting them to other map layers, which we should definitely do anyway).<br>Map layers and other special layers could by default have z=100, z=200, etc, (customisable).<br>(NOTE: for backcompat, we would need to give z values to everything parented directly to<br>the root or map root, equal to the z value of its previous sibling. No big deal.)<br><br>You could throw a projectile in an arc and make it appear over the overhead tree foilage map layer<br>while it's high enough.<br><br>You can make sure objects (slices) on the ground that can be stepped on always appear below<br>all npcs, without resorting to a hack like an extra layer for them<br><br>Building on that, you could give NPCs solid black shadows which don't cover up any<br>objects sitting on the ground (which are drawn below the feet of the NPCs and can be<br>stepped on): parent the shadows ellipses to the NPC slice with Z=0, give the NPC sprites<br>Z=2, and give any object slices parented to the map layer Z=1.<br><br>You could have an NPC standing in water, with their feet appearing below the water<br>surface and things floating in it (a map layer), by splitting the npc sprite into two<br>pieces (bottom and top) with different Z. If you did this without slice Z, you would have<br>to use slices and autosort for the water surface instead of a map layer, and those slices<br>would suddenly snap from above the NPC to behind, which would look really bad unless that<br>slice is just a few pixels high.<br><br></div>
<br></div></div>______________________________<wbr>_________________<br>
Ohrrpgce mailing list<br>
<a href="mailto:ohrrpgce@lists.motherhamster.org" target="_blank">ohrrpgce@lists.motherhamster.o<wbr>rg</a><br>
<a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" rel="noreferrer" target="_blank">http://lists.motherhamster.org<wbr>/listinfo.cgi/ohrrpgce-motherh<wbr>amster.org</a><br>
<br></blockquote></div><br></div></div></div></div></div></div></div></div></div></div></div>
<br>______________________________<wbr>_________________<br>
Ohrrpgce mailing list<br>
<a href="mailto:ohrrpgce@lists.motherhamster.org" target="_blank">ohrrpgce@lists.motherhamster.o<wbr>rg</a><br>
<a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" rel="noreferrer" target="_blank">http://lists.motherhamster.org<wbr>/listinfo.cgi/ohrrpgce-motherh<wbr>amster.org</a><br>
<br></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div></div></div></div>