Descriptive Problem Summary:
SIDE_MAP overlays will flicker/spazz out during SIDE_MAP
Seen by all players regardless of client version on Draemdaemon version 513.1534
Numbered Steps to Reproduce Problem:
Use SIDE_MAP
Apply overlays to target
Code Snippet (if applicable) to Reproduce Problem:
Expected Results:
SIDE_MAP will function consistently
Actual Results:
Overlays seem to take a tiny amount of time to apply or layer properly, giving it a flickering or spazzing effect
I managed to catch a video it happening:
https://streamable.com/ujevew
More prominent example:
https://streamable.com/dfgd52
These overlays are applied on the same plane as the target, but have a slightly higher layer than the target
Does the problem occur:
Every time? Or how often?
Consistently observed with removing SIDE_MAP fixing the issue, but not reproducible in individual instances
In other games?
Unknown
In other user accounts?
Yes
On other computers?
Yes
When does the problem NOT occur?
On objects not using overlays or using TOPDOWN_MAP instead of SIDE_MAP
Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)
Unknown
Workarounds:
Not using overlays or SIDE_MAP
ID:2656961
 Feb 21 2021, 5:21 am
|
|||||||||||||
| |||||||||||||
I cannot make a test case here, as I stated in the body that it cannot be replicated consistently in single test cases.
| |
Without a test case there's nothing I can investigate.
| |
Update, was replicated in other game by separate coder
after: https://streamable.com/3mptai before: https://streamable.com/de7rgn for proof im going to try make a test case again but no guarantees | |
Just for additional information, I use SIDE_MAP and have no issues with overlays, so maybe another factor is messing it up.
| |
Replicated
https://github.com/actioninja/side-view-flicker I initially was testing with all kinds of moving simple dummies, but only movement is enough to trigger glitching with overlays. not side view: https://file.house/zAjZ.mp4 side view: https://file.house/b21X.mp4 Likely the same issue as in http://www.byond.com/forum/post/1998050 and http://www.byond.com/forum/post/1799054 | |
I've downloaded your test case and I'll look into it. I kinda think the older bugs are no longer relevant because the way icons sort with SIDE_MAP has changed completely since then.
| |
I'm not seeing anything wrong in this test case. The overlay on layer 2 is disappearing and reappearing, but it's not flickering; it's winking in and out in a predictable pattern, based on how it's moving amongst turfs that also have layer 2.
As far as I can see this is all correct behavior. | |
Ugh, yeah, you're right, bungled test case that is showing intended behavior. Back to the replication drawing board.
| |
One more time, Replicated
It appears to be an issue with big icons, and for some reason both pixel shifting and the blur filter? IDK what the fuck happen here. Video can be seen here https://file.house/2ngv.mp4 Part of the issue is weirdness to do with big icons and pixel y, there's also an advanced issue to do with pixel y shifted filtered 32x32 icons being crossed by big icons It's aggressively cursed I've written up more details in the readme of this branch, which also holds my testcases https://github.com/LemonInTheDark/basic-test-project/tree/ lemon I really hope this isn't somehow intended, because it's killed a really large year long re-sprite we're working on that needs side_map behavior to function | |
I went into more detail on this in Discord, but it appears the test case is not setting any bounds correctly.
First I set a rand_seed() in area/New() so I could get the same cookies every time. Then I ran this in the debugger. When the pod is dropping, you end up with a deadlock where the pod wants to appear behind its trail because its physical bounds place it at a higher Y. In the case I saw there were two cookies that physically and visually overlapped both the pod and the trail. The cookies had a layer that placed them above the trail, but below the pod. So it ended up with pod < trail < cookies < pod which is a cycle in the topological sort; it had to break that cycle arbitrarily. Because the pod is in a 64x64 icon, it needs its bounds set appropriately. It only uses the middle 32 pixels of width, so and about only the lower 48 of height, so I added this to the code under the pod definition: bound_x = 16 The deadlocks vanished. This is the data: #081: phys 304,288,336,320 vis 230,054,282,106 layer 2.9 (trail) #082: phys 288,329,320,361 vis 224,-09,288,055 layer 3.1 (pod) #083: phys 324,301,356,333 vis 260,051,292,083 layer 3 (cookie) #084: phys 282,299,314,331 vis 218,053,250,085 layer 3 (cookie) Edge #082 -> #081 Edge #081 -> #083 Edge #081 -> #084 Edge #083 -> #082 Edge #084 -> #082 For the physical position, Y increases upward relative to the screen; view position has Y going downward. The topological order between two icons goes like this, in order: 1) If the icons don't visually overlap, they don't care which goes first. 2) If the icons do not overlap on the physical Y axis, whichever one is further back is drawn first. 3) If one has a lower layer, it's drawn first. 4) If one's "near" edge (physical Y) is closer to the top of the screen than the other, it gets drawn first. 5) If one's center is left of the other, it's drawn first. 6) If the two physical bounds are identical, whichever icon came first in the original array order is drawn first. 7) All tiebreakers failed so the icons give up and don't care which goes first. The pod/trail comparison was catching at step 2, saying the pod goes behind the trail. Everything else in that example was catching at step 3. Anyway I don't think the test case proves there's a bug, but you have given me a really good idea for improving deadlock resolution. It seems to me that instead of choosing arbitrarily, it'd be best to try to deal with objects with higher or lower layers first, especially if they're the only one in the group with that layer. | |
I've updated my testcase to include your fixes, but they don't appear to have worked.
* area/New() - I'm not totally sure this is functioning properly, but I put it in * bounds - I wasn't aware that the physical bounds of an object needed to be set to match its visuals for sidemap to function well. Is this the case for all icons? or only large ones. What if I want someone to be able to walk "behind" a big object while still retaining functional display? Does this prevent tile bound projects from using side_map? Onto what strikes me as failures. May be misunderstanding, but it's strange that these are happening. To start with, even though I set the bounds of the pod as you described, it doesn't appear to have stopped flickering. This doesn't go away if I set the cookies below the trail, though I didn't include that here to remain true to your solution. There's three volleys here. The first is the "default" pod. It is being pixel y animated down, and its trails are pixel y set, then blurred. The second volley is the same as the first, but with no blur filter on the trails The third volley is the same as the first, but with pixel z shifted trails  My pet theory is this has something to do with how filters impact visual size, but honestly I have no idea. Maybe I'm doing something wrong? It's worth noting that in that video you can see some clipping on the player's mob. I think this is caused by moving the mob into the center of the tile, rather then at the top. I remember you mentioning something about "position" sorta shifting in blocks, something about trees I think? I wonder if this is linked to that. It'd be nice to have a clearer idea of what exactly it is/a way to turn it off. Is there anything else like it linked to sidemap? To go over the second testcase, I've properly set the bounds of the table. It's hard to show you exactly the same behavior as what I've been seeing cause it's well, random, but walking near the table (typically "above" it visually) will cause the cookies to appear to be confused about their layering. I assume this has to do with big icons? it's very strange.  Code for both can be found here https://github.com/LemonInTheDark/basic-test-project/tree/ post-lummox Sorry if I missed something from the discord convo, I honestly kinda got stunlocked by it. On another note, I'd like to thank you for sharing the actual code for how rendering order is determined, I really appreciate that | |
Correct me of I'm wrong, but the animation is supposed to simulate a ship flying down from a higher space, yes?
If so, is there any reason why you aren't manipulating the ship's pixel_z variable in the animation? That would immediately resolve all of the issues for the ship drop. | |
I am a coder trying to support a massive resprite of one of the larger ss13 codebases.
My concern is less with solving this particular issue, and more with eliminating or documenting what new problems sidemap will bring to the people who come after me. Even if there's a way to solve this on my part, I want to know why it's acting in the way it is, and would very much like to figure out if it's a bug, since if it is and it's fixed I'm saving a lot of time on the part of other future devs. | |
Mem01 is correct that animating pixel_z or a transform is actually the correct method for your case, but still, flickering and layer conflicts shouldn't occur with pixel_y if the bounds are correct. I'll look at the updated test later though.
| |
Sorry if I came off a bit rude. It's just ah, I do know how to fix it, either removing the filter or making it use pixel z does that, it's just I don't know why it's acting that way, and it really worries me.
| |
I'm getting to your test case shortly, but I can give you a more in-depth answer here regarding the blur filter. Basically the topological sort doesn't count objects as potentially interacting if their visual bounds don't cross. A blur filter however does extend those bounds, so you have objects caring about each other's order that didn't before. So it is possible to see a difference based on whether there's a blur or not.
| |
No big rush, man, project's been going a year now, having any progress is more then enough to keep the spriters from hunting me down with pickaxes
| |
What I'm seeing here suggests that the heart of the problem is you're basically setting up a situation that cannot be resolved topologically, and it's always causing a conflict. When I do the default drop I get this straight away in debugging:
#083: phys 304,288,336,320 vis 230,054,282,106 layer 2.9 #084: phys 334,299,366,331 vis 270,053,302,085 layer 3 #085: phys 304,329,336,377 vis 224,-09,288,055 layer 3.1 Edge #085 -> #083 Edge #083 -> #084 Edge #084 -> #085 The way to read that, the physical positions are left,bottom,right,top, in Cartesian space so increasing Y means northward on the screen. Visual coordinates are in display space so that's left,top,right,bottom. All three of these objects visually intersect the other two. Object #83 is one of the drop trails, #84 is a cookie, and #85 is the pod. The #85 -> #83 line means this is the order they should be drawn in, so #85 should be drawn first. This relationship is determined by the fact that #85's physical Y bounds re 329 to 377, whereas #83 is 288 to 320, and since they don't overlap, the nearer object goes on top. #83 -> #84 is because the two objects do overlap physically, but only barely (334,299,336,320), so the next tiebreaker is the layer. #84 is on layer 3, and #83 is on layer 2.9. #84 -> #85 happens for the same reason. The overlap is even tighter (334,329,336,331), but it's still there, so #85 having a layer of 3.1 puts it on top. Thus we have a deadlock. Three objects are trying to decide on their layering order and there's no criteria that gives them a clear answer. As the pod descends there are even more cases like this, but they get more complex. Some of the worst involved as many as 11 icons and 40 comparisons between them. So we've discussed that you really should be using Z coords for the pod and trail and whatnot. That would solve most issues all on its own. But one of the biggest problems in play here is that the trail's layer is nonsensical. You've given it a layer of 2.9, but the cookies and the player mob are on 3. So it's almost baiting a situation where a conflict will occur. One thing the current topological code doesn't do is split an icon into halves to resolve conflicts, which would be a nice future addition but isn't currently achievable. However in this case, there's an overlap between all three objects in the visual rectangle 270,54,282,55, so resolving this completely would be impossible regardless. | |
Layers do not take time to update; they simply don't work like that. So any issue you're seeing is probably a sort problem that's being affected by other things on the map.