Ok, I'll try to remember why to choose the numbers above. For reference:
```
void calculatePriosIso(vector<Renderable> &r) {
	for (vector<Renderable>::iterator it = r.begin(); it != r.end(); ++it) {
		const unsigned tilex = (int)floor(it->map_pos.x);
		const unsigned tiley = (int)floor(it->map_pos.y);
		const int commax = (float)(it->map_pos.x - tilex) * (2<<16);
		const int commay = (float)(it->map_pos.y - tiley) * (2<<16);
		it->prio += (((uint64_t)(tilex + tiley)) << 54) + (((uint64_t)tilex) << 42) + ((commax + commay) << 16);
	}
}
```
The maximum size of a map is 256 tiles in each dimension, because 256 is hardcoded in a few places, such as
the layerdata arrays passed around to renderIsoLayer for example.
The higher the bits are in prio the more important they are. 
The first expression ```(((uint64_t)(tilex + tiley)) << 48)``` is used to determine on which tile we're standing as this is the top priority for sorting. tilex and tiley should be both between 0 and 256 as they are just the position of the entity as integer numbers. The sum of them should be in range 0 to 512. How many bits are required to display a number in range 0 to 512? We need 9 bits, because 2^9=512. So the goal is to put this number in range 0 to 512 in the most upper bits of the prio. Assuming we have a number with 64 bits, the bits are at positions 0 to 63. To put the number into the most upper bits we need to shift the number there, by 63 - 9 = 54 bits. 63 as that is the highest bit position available and 9 because of the number range.

Now for the second part: ```(((uint64_t)tilex) << 42)```
We want to put the horizontal line as next priority into the sorting. The 9 most upper bits are already set, so the very next bit position we could fill is position 53. As we only want to put in tilex, which is in range 0 to 256, which requires 8 bit as 2^8 = 256, the amount to shift would be 53-8=45. Well currently there is 42, so it shifts the tilex value not directly next to the (tilex+tiley) bits, but leaves 3 bit space, which should have no negative impacts.

The very last statement ```((commax + commay) << 16)``` should deal with the order within one tile.
commax is being calculated as ```(float)(it->map_pos.x - tilex) * (2<<16);``` 
So first of all we take the difference of the floating point number map_pos.x and the tilex, which should be between 0.0 and 1.0 as the tilex was just the floored floating point number.

Then to get the floating point number into an integer number suitable for this bit fiddeling, we multiply it by ```(2<<16)```.
This is 2 times 2 to the power of 16, which results to be 2^17 or it could be written as ```(1<<17)```. This indeed smells like an error, but let's see first.

Now that we multiply a number in range 0.0 to 1.0 with 2^17 the resulting number must be in range 0.0 to 2^17.
This number then is cast to an integer and assigned to commax. 
The same happens with commay.

Adding commax and commay will result in a number in range 0 to (2 times 2^17) so in range 0 to 2^18
A number ranging from 0 to 2^18 needs 18 bits for representation, the highest free bit then is 42-1=41.
So we can shift by a maximum of 41-18=23. 
However we only shift the commax+commay value by 16, so there will be a few bits spare again between the commax+commay value and the upper tilex value shifted by 42.

Here is a graphical representation of how I imagine what happens:
![explanation](https://f.cloud.github.com/assets/455868/1733781/f7e9b0ac-633c-11e3-8f98-8f79101823b6.png)

So going through all this, there should be no overlapping of these numbers. (Assuming the initial ranges fit).