Descriptive Problem Summary:
Usually in the Map Editor, Objects(atoms) of the same layer are drawn in the order they are placed on the Map.(Pretty neat and logical)
However, when atoms have a pixel_x or pixel_y (maybe pixel_z also?) components, this is not found to be always true..
This image should explain more clearly.
Numbered Steps to Reproduce Problem:
1.Download the Project
2.Follow the instructions inside the LayerTest.dm
Basically use the Map Editor and see the results based on the objects I have defined there.
Expected Results:
The Atoms if having the same layer should be drawn in the order of their placement on the map.
Actual Results:
Some tiles are drawn under the atoms placed previously..
Does the problem occur:
Every time? Or how often?
Every time when the conditions are true..
When does the problem NOT occur?
Avoid Using pixel_x,pixel_y and maybe pixel_z.
Workarounds:
None known yet... (even though I do have a Hypothesis, =P)
| |||||||||||||
Jul 15 2012, 12:20 pm
|
|
I'd also like to point out something similar exists in Dream Seeker. Overlapping big atoms have their sprites swap layers depending on their position in relation to the player.
|
Yes of course.When I say there is such a problem in Dream Maker I also mean that naturally there is the same problem in Dream Seeker.
|
It's probably worth noting that you're using the depreciated TILED_ICON_MAP format in your example.
However, I am still seeing the "swapping" effect at runtime that SuperAntx mentioned, even after switching to the TOPDOWN_MAP format. |
If it makes any difference (although I mentioned it in its own bug report), SIDE_MAP had some pretty bad swapping and unexpected effects. After a fix or two, it still isn't perfect. Sometimes moving south against the north face of a tall object shows you over it instead of the expected perspective result.
|
A big part of the problem is that the layering engine is not able to fully resolve all cases where objects are on the same layer. TOPDOWN_MAP will not fix this.
The ultimate solution is probably a topological sort, but this has been fairly iffy in implementation. It's something I do plan to revisit. |
In response to Lummox JR
|
|
Lummox JR wrote:
The ultimate solution is probably a topological sort, but this has been fairly iffy in implementation. It's something I do plan to revisit. I hope you revisit soon. |