> I am reading all the replies and trying to see if I am > understand them correctly. > Basically I have two options. Give every movable object the > depth of the screen _y value and make sure that objects can > never be on the same _y position. > Second option. If the movable objects only move one tile at > a time, meaning that their screen _y position could sometimes > be the same, I need to assign for every tile a range of n > numbers of depth that can be taken. Then check for an > available depth within each tiles indivudual range of depth , > when a movable objects is on a tile. > > @Danny, could please explain your comment on subsorting a bit > more. I am not quit sure if I understand it. > > > However, you can optimise quite a bit > by sub-sorting - > if you know that object 1 is in the rear 16 tiles and > > object 2 is in the front 16 tiles, no need to check the z-order.
The best thing would be to look up binary sorting trees, quadtrees and so on (a quick search on Wikipedia should take you to most of the interesting stuff. Essentially, the trick is an extension of what I was describing before: if you know which tile each object is on, then you can sort first by tile, then by sub-tile position. In the same way, you can divide your tiles into groups (usually you'd use a quadtree for this, it's probably the most efficient in this instance) and keep track of which tile group each object is on. If they haven't changed groups, you only need to sort within their current group. The logic should be fairly clear - getting it efficient is a little more complicated, but you should be able to find examples. Whether it's necessary in your case, I can't say. As a general rule, I find these things are less useful than they seem - in the most complicated case, you always have to perform all your checks anyway, so your efficient calculation is going to break down (especially as you've added a big pre-calculation step drilling down through your search tree). If you're relying on your optimizations to keep the game running at speed, it's going to slow down when you hit the most difficult cases. Danny _______________________________________________ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
