[bug] offset + custom screen coordinates

[ozkriff]

Offset moves image to a strange position when used with custom [-1..+1] coordinate system

Demo repository with two binaries: https://github.com/ozkriff/ggez_scale_offest_bug_demo

^ These test apps are supposed to give similar results, but in absolute_coords image's offset moves it to a strange position - towards the edge of the screen.

(maybe this issue is related to #435)

---

UPD: Results in this for Zemeroth:

[icefoxen]

Is this on the master branch or devel?

…

On Sun, Jul 22, 2018, 16:40 Andrey Lesnikov ***@***.***> wrote: Offset moves image to a strange position when used with custom [-1..+1] coordinate system Demo repository with two binaries: https://github.com/ozkriff/ggez_scale_offest_bug_demo <https://raw.githubusercontent.com/ozkriff/ggez_scale_offest_bug_demo/master/demo.png> ^ These test apps are supposed to give similar results, but in absolute_coords image's offset moves in to a strange position - towards the edge of the screen. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#439>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABRfXYBM5dd7BpE3Csc2ziNFiLjoLN2Pks5uJOM5gaJpZM4VaI4q> .

[ozkriff]

0.4.3

UPD: misclicked close button

[icefoxen]

Well, crap.

[robojumper]

How is offset supposed to work? Both examples produce results that are inconsistent with the documentation, which states:

    /// specifies an offset from the center for transform operations like scale/rotation,
    /// with `0,0` meaning the origin and `1,1` meaning the opposite corner from the origin.
    /// By default these operations are done from the top-left corner, so to rotate something
    /// from the center specify `Point2::new(0.5, 0.5)` here.

yet the window_coords example shows that this affects the translation too.

Code for reference:

ggez/src/graphics/drawparam.rs

Line 78 in 98c37ba

translate * offset * rotation * shear * scale * offset_inverse

Making the second example match the first (a fixed offset that affects the translation) is as simple as removing the * offset multiplication from this, while making both examples consistent with the documentation (also producing the same result) is a matter of changing

ggez/src/graphics/drawparam.rs

Line 54 in 98c37ba

let offset = Matrix4::new_translation(&Vec3::new(self.offset.x, self.offset.y, 0.0));

to

let offset = Matrix4::new_translation(&Vec3::new(self.offset.x * self.scale.x, self.offset.y * self.scale.y, 0.0));

because in the code, offset_inverse is affected by scale, while offset is not.

[ozkriff]

The bug is still there in 0.5.0-rc.0, though I confirm that the fix from @robojumper seems to work.

[PSteinhaus]

translate * offset * rotation * shear * scale * offset_inverse

This was the source of this problem, indeed. Multiplying offset into this matrix just didn't make any sense, so we removed it in #880. I'm pretty sure this fixed the problem, therefore I'm closing this now.