The intention in 516 to deprecate bound_x and bound_y was to simplify the coordinate math for working with movables.

When bound_x/y is set, the movable's step_x/step_y can go negative. This is extremely confusing for developers to work with. Prior to 516, the solution was just to avoid using bound_x/y to simplify working with the engine.

Unfortunately, during the alpha, how it shook out, was that we wound up backing down from total removal of bound_x/y from the engine, and the feature added to replace bound_x/y internally wound up being changed from icon_w/z to pixel_w/z. Instead of eliminating what bound_x/y does to coordinates, bound_x/y's visual function was changed internally.

To make matters worse, I reported another issue with pixlocs that makes them unintuitive just like step_x/y when bound_x/y is in play.

Unfortunately, I just think at this point, the whole concept of deprecating step_x/y is no longer workable because of the compromised results from the alpha.

As we spent the entire alpha ignoring bound_x/y and recommending people avoid using it, we basically made 516 harder for people to adopt.

Check out test cases #6 and #7. bound_x/y currently has no viable replacement in the engine, and check out test cases #1-4 to see why pixlocs not being based on bounding box origins has made the new features less intuitive.

I think at this point, the best way forward is to make pixlocs relative to bounds, to ease the complaints that they were intended to solve (moving objects around the world takes too much labor and engine-level knowledge), and to remove the bound_x/y deprecation warning, and abandon the idea that bound_x/y is unsupported.

In addition, bound_x/y deprecation and translating to pixel_w/z has completely broken isometric mode for pixel movement. There is no viable path forward in isometric mode without using bound_x/y. Pixel_w/z is clearly deficient there.