Instance Priorities

[NilG]

I've got another question for you fine folks here about instance priorities.  Basically, I'm not sure how they work to layer instances in a desired manner.

For example, in one of my rooms, the player can open a dresser, which brings up an instance of the openDresser visually on the screen.  No problem there.  Now say the player moves or looks under the clothes.  I switch to a new loop where the clothes are shifted to show the bottom of the drawer, and there's supposed to be a book sitting there.  Functionally, in fact, there is!  But visually, I cannot get the book to appear overtop the dresser instance.  It's initialized but hidden by default; when the clothing is moved, I call show: on it, but no book.

If the drawer's closed and the openDresser instance isn't there, the book shows without issue if I call for it.

I know that instances have Priority properties, and I've imagined this should take control of the layering, but it doesn't seem to matter what I put here; whether the book is a higher priority that the openDresser or a lower, it's just not showing up.

I've seen some similar behavior in other rooms where a couple of instances are stacked on each other; it seems they just appear in some mix of the order they're initialized and displayed in.

Am I off in thinking the instance Priority can be used to direct instance placement relative to one another?  Is this property only applicable to background/Pic priorities?  Is there some other way to prioritizing instances to direct where they show relative to each other?

I know in the above instance I could just add another loop with the book, so it's not like there aren't workarounds, but I'd really like to know if my expectation is off or I'm bungling it up somehow, just so I get it.  Thanks again in advance.

[troflip]

I believe the rules are:

• Views are drawn in order according to their y value.
• A pixel won't be drawn if the pixel previously drawn there (from the background or a view) has a higher priority.

If you need a view drawn on top/behind another view, you can usually achieve this by ensuring their y values are in the order you need, and then adjusting z (or the view cel's placement) so that it's visually positioned correctly relative to the other view.

[gumby]

I can't remember, can where the hotspots are defined on the views effect the y value with this?

[lskovlun]

I think this will be easier if you post the relevant parts of your code.

[Kawa]

I can't remember, can where the hotspots are defined on the views effect the y value with this?

*cough*

A view has worldspace coordinates X, Y, Z. It's world-Y that determines which priority it assumes, unless one is forced via setPri. When drawing, worldspace is turned into screenspace by putting the view's current cel's offset at screenspace [X, Y - Z]. So a view whose offset is in the bottom center and whose X, Y, Z are [32, 32, 8] is drawn with the bottom center at screen position [32, 24]. All this assumes a 320x200 screen, so you can add another 10 for the status line.

(Source: GetCelRect in CELS.S)

[NilG]

Thanks all, I haven't had the opportunity yet to work with the priorities yet, but it's enlightening info.  I'm still curious, as I've tried all sorts of relative priority numbers on two items and haven't found that their relative visibility one-over-the-other is affected, which sounds like it should be the case.  Still seems to default to the y default, from what I can tell based off reading this.  When I get the chance to monkey with it some more, though, I'll take Iskovlun's suggestion and post some code here if things still seem askew from my understanding after reading through here.

[troflip]

Again, y controls the order which things are drawn in each frame, and priority controls whether or not it obscures what was previously drawn. They are different things.

However, they are related, because by default, sprites have their priority calculated automatically based on their y value. So if you're just setting the priority property directly, it will get overridden by the interpreter based on the sprite's y value and the priority bands in the pic background. To specify a fixed priority, you need to use the setPri: method instead (or set the fixPriOn bit on the signal property, which is what setPri: basically does).

[NilG]

Thanks Troflip and everyone.  setpri did do what I needed.  It seems a bit odd to me that a specified priority in the instance code would be overwritten, but that makes sense, and setpri totally does what's needed here.  To follow up, does setting priority: during instantiation do anything, or is it always just overwritten by the y value?

[Kawa]

I'd imagine it still wouldn't set the "fixed priority" bit and get overwritten.

[lskovlun]

I'd imagine it still wouldn't set the "fixed priority" bit and get overwritten.

Let's put that in clearer terms. There's a property called signal in views that does a lot of marvelous things (it's a bitfield, so it represents 16 boolean flags). Among those things are whether the priority is determined by the engine as others have described or not. To make it easier to use, there are methods you can call that manipulate the signal property in just the right way (setPri, stopUpd, startUpd, etc.)

You'll notice in decompiled games, that they sometimes set the signal property to magical values in addition to setting a particular priority. That is how you can avoid having to call setPri directly, but I guess it could be said to be an advanced technique (does Companion support OR-ing constant flags together to make a constant signal initializer?).

[Kawa]

(does Companion support OR-ing constant flags together to make a constant signal initializer?)

As in, can you do (someRandomExampleActor state: (| fixPriOn noTurn)), or have an iconbar button's property list have signal (| icHIDEBAR icRELEASE) instead of $0041? Yes.

[lskovlun]

(does Companion support OR-ing constant flags together to make a constant signal initializer?)

As in, can you do (someRandomExampleActor state: (| fixPriOn noTurn)), or have an iconbar button's property list have signal (| icHIDEBAR icRELEASE) instead of $0041? Yes.

I meant in the properties section, as in

Code: [Select]

(instance someRandomExampleActor of Actor
  (properties
    x blah
    y blah
    priority 9
    signal (| fixPriOn noTurn etc.)
  )
)


[Kawa]

That was the second example I gave.

[troflip]

Yes, I added support for most constant expressions to be resolved at compile time, thus allowing for that to work ;-)

Setting priority in the properties block, and including the fixPriOn flag is how I usually deal with fixed priority sprites.