*WARNING* LONG POST APPROACHING *WARNING*
If you want to skip the context and get straight to the question, just look at the section labeled “THE QUESTIONS”

I've been working on a project that uses isometric graphics, and recently I've come across some issues with layering. Since some sprites are tall enough to block the view of tiles other than the one they are standing on, I have to make sure the sprites appear in front of or behind each other as appropriate.

THE CURRENT SYSTEM

My basic script is this:

(*X) is the sprite's x position on the map, with the axis pointing from the upper left-hand corner to the lower right-hand corner. Thus the number of layers back decreases as x increases.
(*Y) is the sprite's y position on the map, with the axis pointing from the lower left-hand corner to the upper right-hand corner. Thus the number of layers back increases as y increases.
20 is added because the player could be at positions where (*Y)-(*X) is -18, and 2*4=8 gives some bumper room to display sprites that should be in front of everything else, such as a frame, splash, and user interface buttons.
Multiplying by 4 is included as an attempt to combat flickering of sprites which are told to go to the same layer. It gives some “wiggle room” for the jostling sprites, but apparently isn't enough.

THE ISSUES
1) Sprites will sometimes flicker by alternating whether they are in front of or behind something. I believe this is due to too many sprites being sent to the same layer, so they jostle for position and are sometimes bumped in front of or behind another sprite.
2) Sprites with high values of (*Y)-(*X) sometimes end up behind the ZONE sprite (a movable background) even though ZONE is told to go back 500 layers, which is more than the number of layers any other sprite is told to recede.

THE QUESTIONS
First of all, is there a maximum number of layers? There doesn't seem to be much difference between “go back 300 layers” and “go back 1000 layers”.
Secondly, and more open-ended-ly, does anyone have suggestions of how to layer things neatly? Perhaps using lists to record what layer each sprite is on and sorting things out from there?

Note that the sprites that are being layered include both original sprites and clones.

Below is the link to the project if you want to take a look inside. WARNING: MAY APPEAR OVERWHELMINGLY COMPLICATED AT FIRST, but the important part I'm dealing with appears in the sprites “PLAYER,” “COMPANION,” “ITEM,” “FOE,” and “ZONE” in scripts that start with the hat block “When I receive (refresh)”

http://scratch.mit.edu/projects/23813573/

Thanks to anyone who bothered to read through all that…

Additional note: The location where I see the flickering happening the most can be found in-game by following these steps:

1. Choose a character class
2. Walk towards the bottom right-hand corner and go through the gap in the border.
3. Climb the steps at the top right-hand corner of the new zone, cross the bridge, and go through the doorway.
4. Head to the corn maze.

–Danlo

the maximum # of layer's from my experience is either 10 or the # of sprites you have. In essence if you have more than 10 sprites, then if you say go back 999 layers it will go to the very last layer, one layer behind whatever was on the last layer to begin with.

With regards to second question, I'm not sure what's wrong, but when I tried it, the only sprite that had a problem was the sprite itself. All the clones worked flawlessly. So what you may try to do is replace the sprite for a clone and just hide the actual sprite somewhere else.

*WARNING* LONG ANSWER APPROACHING *WARNING*

The main thing to note is that the layer number of a sprite/clone is not like a ‘distance’ from viewer. Rather it's like a position in a list. Telling one sprite to “go back 9999 layers” isn't any different to telling it to “go back 99 layers” if you haven't got that may sprites.

Another thing to note about the layering is that all hidden sprites (and clones) also count in the layer list. If you forget these exist, you may not be going back to the right place in the layer list. That means if you want to put a sprite behind another that you think is at position 5 (say) in the layer list, but you have recently hidden a sprite that was higher in the layer list, then you probably have to send it back an extra layer. (It may be worth sending a sprite/clone back loads of layers when you hide it, just to ensure it's ‘out of the way’…)

Finally, also note that each variable watcher/reporter also takes up a position in the layer list, as do any other reporters you have showing (e.g. “size”, “mouse x”, etc.) And again, that's even if they once were showing, but are no longer showing! What that means is that if you ever show a variable (which brings its display in front) and then hide it later, that variable's reporter is still in front of everything else (but hidden), and you have to take that into account in your layer list…


I had a quick look at the project, and a couple of other things to note…

Once you have the sprites in the order you want, it's not really a good idea to keep switching them around every frame - it'll slow things down a lot. Try to only re-order when something changes.

Whenever you change the layering of a sprite/clone, Scratch gets ready to perform a screen update. That means if you keep doing “bring to front” followed by “go back…”, it will flicker. If you want to avoid any flickering when you “bring to front” then “go back…”, you should put those two into a custom block with non-refresh enabled, and use that throughout the project. I'd recommend you make a custom block such as this instead:

Hope that's helpful!

Thanks to both of you!

It seems I've gotten things to straighten out for now, and I'll look into finding a better system for arranging sprites that are competing for the same layer. I should have realized that “go to front” would start a screen refresh. Knowing that hidden sprites still take up a layer is also useful to know, since I have quite a few of those sitting around in the project.

–Danlo