1
\$\begingroup\$

I have a tilemap in a isometric 2.5 view and i have also many objects moving and static. The problem is many statics are standing in a "integer" place for obvious reasons and the depths of each object is calculated based on their position in the tilemap.

So what happens for some strage reasons is that 2 objects standing next to each other if big enough overlap and if they are in an adjacent diagonal tile they also have the same exact depth, but when drawing the order of same depth object seems random... I draw them in the same order every cycle ofc but the overlapped part of the texture sort of flicker being drawed on top or bottom apparently randomly...

Is there a way to use depth to order objects but make the same depth ones be in some kind of order and not random?

\$\endgroup\$
1
\$\begingroup\$

What you describe here is often called z-fighting, and is a product of the fact that the items have exactly the same depth. Now, while iterating objects to draw, you could check if you've already drawn an object close to it that it might overlap with. You could then set the depthbias of your graphicsdevice's rasterizerstate to make sure they don't flicker. The depthbias should always be VERY close to 0. If you want to make sure one object draws in front of another that has the same depth, set the bias to be about -0.000000001 (give or take a few zero's)

A negative depthbias makes the object come forward, a positive depthbias makes the object go backward.

\$\endgroup\$
  • \$\begingroup\$ yeah i use already this tecnique for a lot of stuff :/ for example i use to expose by a small amount all effects and particles, and give priority to some items over othesr in the same tile and so on... well i guess ill do the same for adjacent tiles and multiply the position for a small factor, i just hoped there was a more elegant way \$\endgroup\$ – user3161621 Jan 17 '15 at 18:01
  • \$\begingroup\$ More elegant would be making sure they don't overlap, or just rendering back to front, never minding depth. But since you said you calculate depth based on its y coordinate, this really is the best i can come up with. Actually, you could integrate it into your calculation and forget about the bias. You want to calculate its depth? Just expand your calculation to take into account other things you have drawn around it that could interfere. \$\endgroup\$ – Peethor Jan 17 '15 at 23:07
  • \$\begingroup\$ i used back to front with no depth at start, but the problem arised when i added stuff like projectiles and particles... there are much more of them than normal objects and i thought it would be heavy to order thousands of particles before drawing them in a back to front system \$\endgroup\$ – user3161621 Jan 18 '15 at 13:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.