Scratch

Well, I'm not sure why, but the absolute layer method I used here seems to work pretty well

http://scratch.mit.edu/projects/Paddle2See/307944

On further reflection, I think the only reason this works as well as it does is that there are a pretty large number of sprites that I'm not concerned with what layer they are on (all the strings and bars).  So they help to break the "layer-space" into a fine enough resolution that the technique works.  I will do further experiments.

Here's my attempt to explain the layering sytem I used in the "Simple 3D World" project at this link

http://scratch.mit.edu/projects/Paddle2See/330704

I hope it is somewhat helpful.

In Scratch, the layering system is relative.  You can position how a sprite will appear relative to the other sprites in the project.  You get a layer for each sprite that you have in the project.  You control how the sprites shadow each other by using the "Goto Front" and "Go Back n Layers".

In the "Simple 3D World" project, I was trying for a perspective look so items that are closer to the bottom of the screen should be in front of items that are higher on the screen.  The little man that lives in the world is in the center of the screen and does not move from that position. 

There are 7 "posts" that move around with respect to the man at the center.  If we look at the extreme conditions, we see that if all the posts were above the man, we would want the man in front of all the posts.  The other extreme occurs when the posts are below the man, then we would want the man behind all the posts.  Intermediate states would require that some posts be in front of the man and some be behind.  This complicated situation would be much simplified if we could just relate the layer number to the screen position.  My approach was to divide the screen vertically into stripes with each stripe assigned a layer number.  Depending on where the object was on the screen, it would be placed at that layer. 

The mapping equation I ended up using was

    Layer # = Round[(60 + (Y position)*.3)/3]

Looking at the equation you can see it has the following properties
   
        At the center of the screen (Y=0) the layer is 20
        At the bottom of the screen (Y=-180) the layer is 0
        At the top of the screen (Y=180) the layer is 40
        The layer will change every 360/40 = 9 pixels

The 9 pixels between each layer was about the minimum I thought I could get away with and still have the effect look pretty good. So to use this method, I needed to have at least 40 layers in my project.  With my 8 objects, I only had 8 layers available to me.  So I added a bunch of hidden "dummy" sprites to bring the sprite count to over 40.  These "dummy" sprites do nothing but give me more layer slots to work with.

Now, with enough layers to work with, the system works pretty well.  Every time the screen is updated, each visible object uses the layer mapping equation to calculate how many layers back they are supposed to be positioned.  Each object then does a "Go To Front" command followed by the "Go Back n Layers" command to position itself properly in the viewing order.  The man at the center always ends up going back 20 layers (since his y position is always zero) but the posts end up moving back anywhere from zero to 40 layers, depending on where they are on the screen.

As I was writting this up, I got to thinking more about what was happening...and I'm not sure why it works as well as it does, given that all the objects update at the same time (in theory anyway), so they are all going to the front, and then hopping over each other simultaneously to get to their proper spot.  You would think they would trip each other up.  The reason I think it works as well as it does is because it doesn't really happen that way...Scratch is not really parallel processing.  And the change in position is gradual so the objects are mostly sorted to start with.