Images clipping improperly in SIDE_MAP format

ID:2389778
 
Aug 5 2018, 6:56 pm
BYOND Version:512.1444
Operating System:Windows 10 Pro 64-bit
Web Browser:Firefox 62.0
Applies to:DM Language
Status: Open
Issue hasn't been assigned a status value.
Descriptive Problem Summary:

When adding images to an atom in SIDE_MAP mode, they do not appropriately display compared to some nearby tiles.



Numbered Steps to Reproduce Problem:

Use SIDE_MAP mode and add an image to an atom. The image only needs to be larger visually, but may use a smaller icon than the original atom. Ex: Image uses 30x30 but original uses 32x32. Changing the size of the icons does not seem to changes anything, images seem to always affected in this way.

KEEP_TOGETHER does not resolve the issue either. Filters applied while using KEEP_TOGETHER (such as outline) make this issue more obvious.

Aug 5 2018, 8:57 pm
Update: I've noticed this only happened when I started to use bound_x/y to properly modify my hit box based on the icon. Perhaps the SIDE_MAP layering code is not taking bound_x/y into account?
Aug 5 2018, 10:09 pm
Can you shoot me a test project?

Probably what's happening is the image isn't being given separate bounds. A test case will go a long way toward helping me fix the issue.
Aug 6 2018, 5:10 am
I tried putting together a test project but was unable to get the same results. I'm not sure exactly why, but the only difference between the two projects is that the icons being used in the example above are very old. Was something changed along the lines in icons to affect layering on SIDE_MAP?

As well,I noticed the issue happens to the base atom as well, not just the image. It's very strange.
Aug 6 2018, 10:26 am
Sprite ordering in SIDE_MAP is now based on these factors, once planes and such have been accounted for:

1) Collision bounds, modified so that they extend to the near edge of the atom (e.g. if bound_y > 0 it acts like it's 0), and also taking pixel_x/y but not pixel_w/z into account.
2) Layer
3) Original order in the list

The #1 rule modifies the collision bounds so certain edge cases are handled gracefully, like the tree in Ter13's demo for the more recent bug. His tree's bounds are technically compound, but it's a common enough situation that I felt it important to honor that case.

If you can't put together a test case it would help to know the bounds and current step_x/y position of the parent object, plus its pixel_x/y position, along with any and all information about the image. But please do try to get a test case, just by paring down what you already have, because I need to get to the bottom of this.
Aug 6 2018, 8:28 pm
I'll see what I can do but I'm kind of scratching my head on it haha.
Aug 21 2018, 11:01 pm
Any ideas yet, Bravo, or code I can look at for the objects in question?
Aug 22 2018, 4:03 am
Unfortunately I'm completely unable to replicate the issue. It may be best to close this for now. Sorry =(
Dec 5 2023, 6:51 am (Edited on Dec 5 2023, 7:48 am)
Seems that I was able to reproduce this bug.

https://cdn.discordapp.com/attachments/725458598213451879/ 1181607259814498345/SIDEMAPTEST.zip?ex=6581ac83&is=656f3783& hm=8ac43105ee8b8331397548a74043ab94ea9166485aef0918139cc5dfd 986d8c4&

EDIT:

So what I've found is that bound_x/y plays into calculation for SIDE_MAP's drawing order in rather unexpecting ways.

So it seems that the render assumes that all of the sprites must have the same starting points. So if one the atoms has a greater bound_x/y, that atom's "starting point" is considered to be further ahead. For example:

atomA has a bound_y of 24.
atomB has a bound_y of 6.

As a result, the calculation for whether atomA will be drawn first or second is offset by an additional 18 pixels (in terms of position). This is clearly not intended behavior.

My explanation may have sucked. HMU on discord if you have any questions.