An inherent part of the problem here is that the plane master is a texture the size of the map.

For translational transforms on a plane master, it does seem that it'd be doable to simply adjust the bounds for its children, and remove the translation (leaving any remainders from rounding). That at least would solve your issue.

For rotational and scaling transforms, that's a much bigger problem.

Descriptive Problem Summary:

Objects sharing a plane with a scaled plane master experience odd position and occlusion updating.

The position of the objects relative to others on different planes slides as one would expect in a parallax background setup.

As well, objects at the edges of the view-able area are occluded.

Numbered Steps to Reproduce Problem:

create a plane master and scale it down. Create objects on the map with the same plane and move around, taking note of the edges of the client view.

Workarounds:

It's likely possible to update the planes transform to update the position properly in order to counteract the position (I actually don't want this as it's already doing what I intended to, but it's doing so incidentally rather than intentionally), and it's possible to decrease the window size to hide the portions of the map where objects are being occluded.


Test file: https://www.dropbox.com/s/jpc37e9jf3wsxy8/testcase.zip?dl=0

The brite white tiles are appearing above the black letterboxing border for a few pixels when he moves such that they are out of view.

He hinted to some positioning bug as well but i'm as lost as you are.

So he has a scaled up (transformed) planemaster and the objects are moving in world in the same scaled up rate when the mob moves arround.

Close,

The Dim areas are scaled down (0.95) which causes them to move at a faster rate that the lighter tiles, even though the only scrolling going on is BYOND's built in scrolling. As well, the darker tiles are getting clipped earlier than they should be, causing them to disappear earlier than the white tiles, even though they aren't yet at the edge of the map.

The version is 512.1397(latest)

I was using that one to make sure I didn't have an outdated one, but I'm unsure how far back the issue goes. It's possible it occurred when plane masters were first added.

Can I make a request lummox? Can you find a way to allow us to keep that bugged behavior (optionally)? I actually know of a really good use for it for /tg/.

Agreed on this as well, it's bugged, but it's actually a feature I was looking to implement as it allows for a nice parallax background effect. If the tiles are shrunk down, and then moved at a slightly faster pace in order to stay aligned, then you get the effect seen in games like Steamworld Dig 2 (which looks really good).

That being said, if the bug is fixed, it's enough to get it working manually as a feature. The biggest issue for me is the clipping, where the edges of the tiles are being cut off earlier than the edge of the map area.

I agree it's tough to see out-right, but check out the included test case and it should be easier to see the issue.

My guess as to the issue here, at least with the clipping, is that since plane master gets all the stuff on the same plane to draw on a surface the size of the screen, shrinking that surface isn't currently accounted for, so the "edges" where display processing would normally end are still there, even though scaling it down (smaller) should show more (as if zooming out).

I was wondering if that might be the case.

In your response on that thread, you mentioned that the clipping should be done at the end by simply applying all transforms individually on the plane. With transforms alone and when no rotation or scaling is going on, that's not a problem; the plane's transform can be taken out of the equation and given to everything beneath it, at least when rounded off to the nearest pixel. Where other transforms mix in, that's where things get sloppy.

For instance if a plane master is rotated 30° and then transformed, if those transforms were given to individual objects and you did a slow animation, you'd probably see a "crawling" effect. Without scaling or rotation in play, just trsnaforming every tile by partial pixels would potentially cause a crawling effect too.

Plus, filters are applied before the plane master's transform, which would impact them as well.

I suspect the only truly viable solution here is to recalculate a plane master's true bounds based on its transform, and enlarge/move the surface as needed.

I'm looking into making the change.

Under the hood, you also need to make sure your view is large enough to incorporate the background since you're scaling that down. There's a bit of overflow included in the drawing, but you still need to be aware of that.