Now we are facing a new problem with the buildings. The buildings are not well placed on the map. They overlap with each other in a very strange way. That is because we are now viewing the 3D isometric world in 2D screen with wrong ordering.
When we view the 3D perspective in the following way, the closer objects should block the view of the objects behind. The buildings in the preceding image do not obey this real-world rule and cause some strange overlapping. We are going to solve this problem in the next section.
In Flash, every movie clip has its own depth. The depth is called z-order or the z-index of the movie clip. A movie clip with bigger z-order number is higher and covers the others with lower z-order when overlapping. By swapping their z-order, we can rearrange the movie clips on how they overlap and create the correct ordering of isometric buildings.
According to our tile-based isometric map, the object that locates in larger number of the x and y axis is in front of the object that locates in smaller number of the x and y axis. We can thus compare the isometric x and y coordinate to determine which object is in front.
There is a special case when all shapes of the buildings occupy square shapes. In this situation, the order of the movie clip's z order can be easily determined by comparing their y position.
Different buildings occupy different sizes and shapes on the map. We need to be careful of the shapes of the buildings and how it occupies the map. Different sizes and shapes of the buildings result in different ways of sorting the z index of the movie clips to make the three dimensions looks correct.
In l-shaped buildings, there is no simple way to render the z-order correctly. No matter how the tree's z-index is, the render result is incorrect. This is because the concave corner of the l-shape makes it difficult to order correctly with other's objects.
To fix the z-ordering problem of l-shaped buildings, we can either split the l-shaped buildings into several rectangular buildings or mark the whole bound of the building as unwalkable.
If the virtual world contains a rectangle shape for building, we have to compare the y-axis and then x-axis of the isometric coordinate to determine the z-order of two buildings or avatars. The buildings or avatars with bigger isometric y and x number are in the front.
Take the following buildings as an example. Building A has bigger y-axis than building B, and building B has bigger y-axis than building C. Therefore, building A is in front of building B which is in front of building C.
Square is a special case of a rectangle-shaped building. Because of the special symmetry shape, objects with y position in bigger screen coordinate are always in the front. We can simplify the sorting algorithm by only comparing their y position in screen coordinate to determine the correct z-index if the virtual world contains only square shaped buildings. In our virtual world example, all buildings are in square shape.
We have a loop running every frame for the walking of the avatars. We will insert the sorting z-index code in this loop.
for(var i:int =1;i<_sortableContainer.numChildren;i++){
var mc1:DisplayObject = _sortableContainer.getChildAt(i-1);
var mc2:DisplayObject = _sortableContainer.getChildAt(i);
if (mc1.y > mc2.y){
_sortableContainer.swapChildrenAt(i-1,i);
}
}
Normally, we can use bubble sort for sorting small amount of elements. Bubble sort is easy to implement and it repeatedly compares two adjacent elements and swaps them if the bigger one hasn't come first. The sorting algorithm we used is similar to the bubble sort. However, if you take a closer look at the code, you will find that it is actually a bubble sort without the outer loop. This is a single loop sorting, that only compares and swaps adjacent movie clips' z-index.
There are two reasons that this is not a complete sorting algorithm.
One reason why we omitted the outer loop of the bubble sort is that this function is already executing in every frame. The enterframe event acts similar to the outer loop already and the difference is that the enterframe event runs 30 times per second according to the frame per second. It will sort all the objects within seconds.
Is this one or two seconds delay of sorting acceptable? Yes, because there is another important reason. When an avatar is walking, it may move from the front of the building to the back and we need to sort them again. In most cases, the avatar only swaps the z-index with its adjacent building each time; this fits our sorting loop because the loop only sorts adjacent objects on each frame.
Moreover, by omitting the outer loop, we can make the sorting much faster which prevents dropping frame rate when there are many buildings and players on the map.