# [PATCH 1/3] wined3d: Don't shift geometry for d3d10/11.

Henri Verbeet hverbeet at gmail.com
Tue Aug 10 09:18:31 CDT 2021

```On Tue, 10 Aug 2021 at 14:51, Stefan Dösinger <stefan at codeweavers.com> wrote:
> > Am 10.08.2021 um 15:09 schrieb Henri Verbeet <hverbeet at gmail.com>:
> > For the "left" part of "top-left"; we don't flip the x-axis, but we
> > still want to make sure we get the convention Direct3D applications
> > expect.
>
> My head is flipping upside down every time I think too much about coordinate systems, but I think that's wrong. We aren't rotating everything by 180 degrees around z - we're flipping around the x axis, swapping front and back. As evidence, we have to adjust the winding order based on yflip.
>
> If you twist a clock in such a way that it now runs counterclockwise and 6 is at the top and 12 at the bottom, then 9 will still be on the left and 3 on the right. Or like a mirror on the floor you are standing on. Your left and right will be alright, but suddenly your up and down are flipped and the watch will still run counterclockwise in the reflection. In the situation you are thinking of (6 top, 12 bottom, 3 left, 9 right) the clock still runs clockwise.
>
> Am I missing something? I am sure that even if my thinking is right I've got some part of the explanation wrong...
>
I don't think it's quite that complicated, but it probably helps to
conceptually separate the half-pixel offset from the
filling-convention offset. I.e., there are two translations involved
(only considering d3d9 and the x-axis for now):

- We translate by 1/2 pixel to the right to account for pre-d3d10
pixel centres.
- We translate by ε to the left, so that a triangle covering the
right half of a pixel from top to bottom exactly through the pixel
centre ends up generating a fragment for that pixel, and a triangle
covering the left half of that pixel doesn't.

The total translation is then (1/2 - ε) to the right, independent of
anything we do to the y-axis. Without WINED3D_PIXEL_CENTER_INTEGER the
1/2 pixel offset goes away, and we end up with just -ε. Now if we can
detect that the OpenGL implementation already uses the Direct3D
filling convention, we can instead simply use 1/2 as offset with
WINED3D_PIXEL_CENTER_INTEGER, and 0 without.

```