SIDE_MAP + Pixel Movement in Bug Reports

ID:120053
 
Oct 16 2011, 12:40 pm (Edited on Oct 16 2011, 2:30 pm)
BYOND Version:493
Operating System:Windows 7 Home Premium 64-bit
Web Browser:Firefox 7.0.1
Applies to:Dream Seeker
Status: Verified
A member of our crack team of bug testers has verified that this issue is reproducible, and has handed it off to the development team for investigation.
Descriptive Problem Summary:
SIDE_MAP doesn't get along well with pixel movement. Though it provides graphically superior, simplified layering (to the point that it should probably be the default map_format), when used in combination with pixel movement it is heavily glitched, from things completely disappearing to halfway appearing behind other objects, to inconsistently broken layers in the map editor (that map editor part probably doesn't involve pixel movement...)
As you can see in this screenshot from LoP, at various pixel locations some objects/tiles will shift layers. PO has similar conditions, in combination with a focus on big-icons, where the problems become even more apparent. Houses and Trees (which are both big .png files) will randomly flicker in and out of existence as you walk around. As seen in this screenshot from PO, the player seems to have lowered his layer, not only is he under the ground, but also under his pokemon.
It seems as though this was reported before, Supposedly resolved issue.

Expected Results:
SIDE_MAP provides consistent layering effects, in both the map editor and in-game.

Actual Results:
Pixel movement seems to cause terrible glitches in SIDE_MAP, and the map editor occasionally displays incorrect layering as well, especially if 2 big-icons are overlapping.

Does the problem occur:
Every time? Or how often? Every time, but not all the time.
In other games? Yes
In other user accounts? Yes
On other computers? Yes

When does the problem NOT occur?
If you don't use SIDE_MAP and/or pixel movement?
#1 Oct 16 2011, 4:19 pm
Yes, there are still some known issues with the layering. The problem is, layering is a difficult thing to do correctly in non-transitive situations and even though SIDE_MAP isn't isometric, it still introduces some potential non-transitivity. That should really have been posted separately in the first place instead of as a followup to the other issue, so it's good to have this separate report now.
#2 Oct 16 2011, 4:46 pm (Edited on Oct 16 2011, 4:59 pm)
I don't see where the problem is, especially in non-isometric maps? The lowest coordinate object should just be the highest, basically a reverse y layering system, taking actual layers into account as decimals perhaps?

So, if an /obj is at 1,1,1, of a 100x100 map, its layer would be 99.3, for example. Pixel movement would just need to use pixel coordinates instead of tile coordinates, but should amount to the same visual results, with a much larger span of layers.
#3 Oct 16 2011, 4:57 pm
In many cases a turf will have a lower y coordinate than an obj on it. Because of this, it's easily possible to come up with cases where a topological sort is required at minimum to fix the issue, because a simple sort fails utterly. Consider this example:

XX
XX  YY
AA  YY
AA  BB


A and B are turfs, and X and Y are objs. Now obviously X and Y don't really care about their relationship to one another because they don't overlap, but a non-topological sort requires that the relationship between X and Y be known. X should appear behind A, in case A is taller. But Y should appear in front of B.

In a simple quicksort, this situation cannot be resolved.

I have some tentative code for a topological sort already, but it still needs work. In SIDE_MAP I managed to make some good strides toward a solution, but there was a test case still failing that I couldn't work out. Isometric is more difficult still; to properly resolve cycles, icon pixels actually have to be compared to see whether they truly touch or not.
#4 Oct 16 2011, 5:05 pm
What if turfs were always layer 1 (or whatever lowest layer was needed)?
#5 Oct 16 2011, 5:08 pm
It still doesn't work. Topological sorting is really the only true solution. Besides, users do have the ability to set the layer for the turf and that does have meaning; it shouldn't be abandoned. After all, an obj that is just 0.1 layer above a turf is probably meant to behave in a very turf-like way itself as far as layering, so handling this more generally is for the best.
#6 Oct 16 2011, 5:16 pm (Edited on Oct 17 2011, 5:05 am)
Turfs already have severely limited functionality, I don't think it would be much of a loss.

As for low layer objects? I would need a more specific suggested usage to contemplate those...
EDIT: Maybe another special layer could be implemented for things that you want to appear above turfs, but below everything else?

From my limited experience with pixel movement & SIDE_MAPs, it seems like turfs layered as the ground, and everything else layering by coordinates (completely disregarding developer assigned layers) would work, but I probably haven't considered every situation.

EDIT 2: With the way turfs work now, especially taking big-icons and pixel movement into account (turfs can't have bounds, for example), they can most effectively only serve as a ground/background for your map. Then there's the previous functional limitations, like how all turfs in a tile are stacked into a single turf as underlays, how said underlays force directional changes, how pixel offsets just leave black holes, etc...
#7 Oct 17 2011, 6:26 am (Edited on Oct 17 2011, 8:36 am)
I have implemented my own layering system to accomplish what I suggested below. So far, it works at producing the desired effect, but after going into a battle severe graphical lag occurs when moving NORTH/SOUTH (unsure why at this point). I also had to use somewhat awkward layers for HUDs, I simply multiplied them by 10,000.
EDIT: Found out what was causing the graphical lag problem.

This was done in less than 10 lines of code, a simple layer shift in /atom/movable/Move() for the most part.

I've also come across a low-layer object already (a chair). I simply set it to TURF_LAYER, and had my layering system ignore any /movable atoms on TURF_LAYER...