On Fri, May 20, 2011 at 11:29:20PM +1200, Ralph Versteegen wrote: > On 19 May 2011 12:10, James Paige <[email protected]> wrote: > > On Wed, May 18, 2011 at 04:17:36PM -0700, [email protected] > > wrote: > >> james > >> 2011-05-18 16:17:36 -0700 (Wed, 18 May 2011) > >> 158 > >> Hit CTRL+F9 debug key twice to enable a mode that toggles drawing NPCs and > >> heroes old/new style on every tick, making any differences stand out by > >> flickering > > This is great! I'm so glad this has finally been done (And I didn't > have to do it :) > > > Right now the only flaw I can find in the new display is vehicle > > shadows. If anybody spots any other differences, let me know. > > NPCs should not be Y-sorted, they should be sorted by NPC reference. > Several other complaints below.
Right. I was wanting to make an alternate mode that puts NPCs and Heroes in the same layer and Y-sorts them all, but for the current mode it should indded be consistent with the old behavior of sorting by NPC ref. > Here is how I imagined that the walkabout slice system should work: > > Expand the "NPCs above Heroes/Heroes above NPCs" option in the map > settings to include a 3rd setting, "Y-sort all NPCs and Heroes". It's Perfect > kind of unfortunate to have this a per-map option though. There could be four options. NPC over Hero, Hero over NPC, All Together, and Use Default, with the default being in the general game data menu. > The existing > two options would cause there to be separate NPC and hero walkabout > layers, as you currently have (except the NPC one should not be > sorted). The new option causes all NPC and hero slices to be parented > directly to the 'Walkabout' root slice, and sorted. Exactly. > We should add an option to slices to automatically sort their children > (by the 'sorter' value, nondestructively, and maybe also support Y > sorting). Then sorting of walkabouts is accomplished just by turning > this on by default for the walkabout layer(s), and people can easily > override this if they want to. Ah! That is clever! I wonder where the auto-sorting should be applied? In DrawSlice or in AdvanceSlice (or does it even matter?) > I assumed all walkabout container slices are the same size (the size > of a tile) regardless of the actual size of the sprite, so that > Y-sorting and "Z-sorting" (where the Z value is the Y-value of the > bottom edge of the sprite and is stored in the custom "sorter" member) > are equivalent, and we can just do Y-sorting. Yes, you assume correctly. > I wonder whether this > might ever change? Maybe for pixel-based movement the container size > could be the obstruction size of the walkabout? Hmmm... tricky... Yes, that probably would be most appropriate. It means that at that time we would have to switch to sorting by slice center or by slice bottom center, instead of sorting by top-left. And I guess it makes sense to do that now... > ALSO, I definitely would not create blank invisible slice container > for non-existent heroes and non-existent and disabled NPCs. This will > be a total mess when anyone actually wants to look at the slice tree > (via the slice tree dump debug key or that slice tree viewer we > should^W will add in future), or use the "slice at point" command. And > what's the point of having blank placeholder containers anyway once we > have no limit on the number of NPC instances? I agree. I just wanted to keep get things working first, and figured that would be an "optimization" step :) > Also we should store a pointer to the walkabout container in the NPC > and hero structs rather keeping that npcsl array and searching through > it. I was going to put the npc slice pointer in NPCInst but udts.bi doesn't include slices.bi yet, and I wanted to think about whether there were any undesired side-effects of doing that before I did it. I figured it would be easy to change later (thinking back it seems like a dumb thing to have worried about ) > > It also looks like adding NPC z coordinates for all NPCs will not be > > much extra work either-- that is to say, getting NPC z up to the level > > of Hero z will be pretty easy. Larger and trickier problems remain, like > > having an option to sort heroes and NPCs together on the same layer, or > > figuring out some fancy way to tie walkabout Z value to which map layer > > a walkabout sprite gets drawn on top of (and the more I think about that > > last one, the more I think that along that path madness doeth lie in > > wait with many snapping jaws and slavering tentacles) > > I hope that reading/writing the Z value of an NPC just reads/writes > the Y value of the walkabout sprite slice relative to its parent (and > negated), Oh! yes! That is wonderful! Why didn't I think of that? I will definitely do it that way. > but I'm open to also doing automatic reparenting. But I > think there are two main reasons you would want to do this: multiple > movement layers (eg. bridges) which we would want to approach properly > (by having multiple walkabout layers each with its own wallmap and > obstruction testing), and more genuine 3D systems, where you want to > move objects above or below weather/effect layers which have actual Z > values (I think you would need to create objects like trees and > buildings using slice-based (maybe NPC-based) "map objects" rather > than tile layers). Yes. For now I won't worry about any automatic reparenting. That can come later if/when we get multiple wallmap layers and multiple walkabout layers. > I think it'd be a good idea to only semi-protect walkabout container > slices to only disallow deletion, so that people can reparent them to > map layers. Okay. I am cautious but optimistic about that one. I was worried about sorting before, but based on your suggestions for how we should handle sorting of walkabout layers, I feel safer about allowing a reparenting exception to walkabout slices.... Oh.... there is still one problem. I don't want to allow reparenting of NPCs to a non-protected parent, because then you could free the parent and the walkabout would get freed, and then the NPC or hero would have a dangling pointer. But since map layers are protected that should be safe. > This reminds me about the footoffset. I think that footoffset should > be added to the Y value of a walkabout sprite relative to the > walkabout container slice, not to the container slice's Y value. Excellent point. I had not thought about foot offset. That does mean we need to compensate for foot offset when getting/setting z values, but that is no trouble. > I > would like the position of the container slice to be identical to the > position returned by "npc/hero pixel x/y", and isn't that much saner? > But I'm not sure whether that's possible with map wrapping. It would > be nice if you could parent stuff to the walkabout layer and not have > it break when the map wraps; I'll have to think about it. Hmmm. Yeah, no idea how to deal with wrapping slices, although yes, making npc/hero pixel x/y match slice x/y is indeed desireable. --- James _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
