I appreciate the deepdive.

Layering like that being an issue initially strikes me as strange, maybe because I'm used to layers and planes being absolute, which of course can't really work here, that's sorta the point. I suppose in a real world example you'd want the trail to be above everything but the pod, excetera, which is close to the effect of zshifting regardless.

I am a little worried about the blur filter though. Maybe it ties into what you said about splitting icons up to more cleanly resolve conflicts? (I've seen some other strange behavior where one object pixel x shifting up caused re-layering on a vastly different part of the map, but that's a separate concern)

Is the implication that the blur filter is just like, unusable? Even with a more sane layering setup the blur filter seems to still cause almost all of the visible issues. Is that intended? Is it just the result of moving a "big" icon" cause it looks really really odd, and I'm having a hard time justifying it to myself.

I'm assuming the issue with my second testcase has something to do with the bounds of the cookie icons? Honestly I'm a little unclear on the rules of sidemap and such. Maybe I missed some documentation, but bounds coming into this at all was a total surprise to me. Some extra clarification would be very nice.

I'm a little worried that every object needs pixel perfect bounding to work, that'd be just a death nail honestly.
In response to LemonInTheDark
The blur filter isn't unusable. The trick of this is that SIDE_MAP takes more thought to use properly and there are situations where it simply can't resolve conflicts if it isn't used with care.

The problem isn't the blur filter; the fact that it impacts visual bounds is just making existing conflicts more likely to come up. The real problem is that the pod drop and its trail were done without giving enough thought to layering or where they actually are in the world. A layer of 2.9 for the trail was always nonsensical; it's the main reason you ran into problems.

SIDE_MAP and ISOMETRIC_MAP modes have to make some sacrifices because of the fact that atoms in BYOND do not have 3D coordinates. Instead, atom bounds are used to determine physical position on the 2D plane, but for 3D position the only thing they have to work with is the layer; there is no physical height.
Are you sure it's not at least partly the blur filter? It happens even if I put the pod/trail on layers higher then everything else on the map.

The issue also only seems to effect things that are being pixel shifted vertically. If I remove the random offsets, things are fine, but if I shift them all by say 1,1 consistently, everything starts to freak out. Same can be said of the mob's position and that strange clipping too I think.

I don't want to bother you too much, but something really seems wrong here.

Here's an updated branch, if it's useful to you. You can check the commit history for details, but I basically just pumped the pod/trail's layer to the max, and added staticly shifted cookies to the far right end of the map.

It seems strange to me that any pixel y shifting causes this behavior.

https://github.com/LemonInTheDark/basic-test-project/tree/ post-post-lummoxism
In response to LemonInTheDark
LemonInTheDark wrote:
Are you sure it's not at least partly the blur filter? It happens even if I put the pod/trail on layers higher then everything else on the map.

I've explained at great length why the blur filter is not the issue. The expansion of the visual bounds that's caused by the blur filter is merely making existing inconsistencies in the layering/positioning more likely to appear by having more objects overlap one another.

Stop focusing on the blur. The blur is not the problem.

The issue also only seems to effect things that are being pixel shifted vertically. If I remove the random offsets, things are fine, but if I shift them all by say 1,1 consistently, everything starts to freak out. Same can be said of the mob's position and that strange clipping too I think.

Of course you're going to see less of an issue when everything aligns to tile bounds; in those cases you have very clear and consistent ordering just due to layering.

There might be a case to be made for allowing visual filter overflow to impact the physical bounds, at least in terms of how sorting is done. The biggest issue here is that you have a major disconnect between the visual bounds and physical bounds and it's creating situations where the sort can't resolve conflicts. With correct application of Z rather than Y, I doubt any of this would be an issue.

Considering your trail is made of multiple icons, using a normal blur is the wrong choice anyway; you'll have the individual icons blurring over each other. What you really want here is motion blur in an x-only direction. That would eliminate the vertical visual overlap between trails and turfs that makes these conflicts possible.
Oh lord I think I see.

The objects and trails are flicking in and out of existence because the tile they're on is being pulled into layering conflicts.
It used to be that this was because of the strange layer vars of the trails in comparison to the cookies, but currently it's because the trails are overlapping each other due to how the blur filter "blurs" them down. S nothing to do with inherent big icon things.

It's nothing directly to do with the pixel shifting either, it's just that the cookies have a 32x32 bound, so if they shift together, one entering a "conflict" causes the rest of them to be pulled into the mess. That's why a conflict from the trail on one side of the screen can cause flickering elsewhere.

I think my initial hangup here was the assumption that sidemap's "in front of" logic was just based off y + pixel y, rather then that and the bounds of the object. That's honestly kinda on me, we can't actually use bounds in the project I work on since it breaks our movement.

I'm sorry, but I still don't really understand the distinction between visual and physical bounds, it seems like they'd serve similar purposes?

Kinda on that topic, do you know why moving side to side like this might cause flickering? It's odd, because nothing I've found in this system seems to be random, it's totally deterministic, which makes this sort of thing strange. Is it because the frame of reference has changed?

(This was with a change that moved the turfs to a separate plane)

The visual bounds are effectively the bounds of the icon itself, plus the transform and any effects like filters. The physical bounds describe the atom's footprint on the map.

I think the flickering you're seeing when moving from side to side is mainly that there are still inherent conflicts between all the atoms in the scene, and those conflicts are resolving differently as objects move on and off the visible map. The resolution of those conflicts is always deterministic, in the sense that there's no pseudorandom behavior in the algorithm, only arbitrary behavior.
The issue is the trails conflicting with each other right? and then that conflict sort of "infects" other objects inside the visible bounds of each other.

If that's the issue, and the filter is purely expanding the visible bounds, wouldn't the trouble be caught by step two of the ordering process? Or am I misunderstanding something again.
In response to LemonInTheDark
The issue is the trails conflicting with everything basically. The whole setup with the cookies is already taxing things.

If the algorithm were capable of cutting sprites into pieces to resolve conflicts, most of the issues you're seeing would vanish.
I guess I don't understand why they're conflicting in this state. Or even the cookie thing really, since if you shift them all in one direction I'd think the state of the bounds would stay the same.

Don't want to pester you with testcase on testcase tho, seems like a waste of time.

Would you like me to make a feature request for the sidemap changes you've mentioned here? Cutting into pieces/doing extra layering by the layer var.

It'd also be really nice to have more detailed documentation on how sidemap works, at least in the ref. What exists now is really kinda barebones, and it'd be nice to have a place to point people in future.
I realize that's a lot of work though, so I may just make a guide in my own codebase.
I've written up some feature requests for the changes you've mentioned here.

https://www.byond.com/forum/post/2784074, https://www.byond.com/forum/post/2784076, and https://www.byond.com/forum/post/2784077.

Being honest, I have a feeling most of the "bugs" we've run into with sidemap have just been intended behavior that's been poorly understood. I don't think the format itself is inherently broken or anything, just really kinda poorly documented (Outside of something weird I'm aware of with vis_contents, unless that's also intended behavior in which case I'm gonna quit this whole coding thing).

Edit: I figured out what was going on with vis_contents, we were using VIS_INHERIT_PLANE, so everything got rendered as it if was on the same plane, which really fucks up rendering. See https://www.byond.com/forum/post/2784126

Big icons are still really strange, and the way their odd behavior is just sorta handwaved away as "it just is that way" in the ref is confusing, but I don't think any of this droppod stuff is a bug with the system, just one with my brain.
Page: 1 2