[PATCH v2] ddraw: implement Pick() and GetPickRecords().

[Vijay Kiran Kamuju]

Implement functions used by some games (notably LEGO Island) for
determining which 3D object in a scene was clicked by the mouse cursor.
Fighting Steel also uses this function for mouse over. Previous stubs
would cause LEGO Island to crash upon any click and Fighting Steel
to crash on game start. A patch posted years ago on the bug thread
provided the minimum functionality to prevent crashes, but still
rendered large portions of the game inaccessible without them
implemented correctly.

Picking has been implemented by adding a "pick mode" in
d3d_execute_buffer_execute() which skips any drawing functions
leaving just the vertex processing. Adds click tests for each triangle
when in pick mode for creating an array of D3DPICKRECORDs.

Add a D3DPICKRECORD array and DWORD counter to d3d_device. These are
initiated in d3d_device_init(), allocated/written in
d3d_execute_buffer_execute(), and accessed/read in
d3d_device1_GetPickRecords(). The counter is used to determine the array
size (0 meaning array is not allocated). The array is free'd whenever
the data is no longer necessary by d3d_execute_buffer_execute(),
d3d_device1_GetPickRecords(), and d3d_device_inner_Release().

Add a compliance test to ddraw1 to test whether certain screen points
result in successful picks or not, as well as whether the data returned
from GetPickRecords() is valid and correct.

Stress testing reveals this patch's Pick() implementation may have
slight inaccuracies to the original function; occasionally pixels right
on triangle edges result in successful picks when they don't with the
original function (and vice versa). It may be some sort of floating
point rounding error or other algorithm difference that would be
difficult to determine without seeing the original code. In practice, I
believe this inaccuracy is so negligible that it won't produce any
undesirable results for the user.

v2:
Rebased to latest code (Vijay Kiran Kamuju)

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=10729
Signed-off-by: Matthew Wong <itsmattkc(a)gmail.com>
Signed-off-by: Vijay Kiran Kamuju <infyquest(a)gmail.com>

[Marvin]

Hi,

While running your changed tests, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?

Full results can be found at:
https://testbot.winehq.org/JobDetails.pl?Key=67780

Your paranoid android.


=== w1064v1809_ja (32 bit report) ===

ddraw:
ddraw1.c:7717: Test failed: Got unexpected color 0x00000000.
ddraw1.c:7719: Test failed: Got unexpected color 0x00000000.

[Stefan Dösinger]

Hi Vijay,

Halfway through reviewing this I couldn't help but have a dejavu feeling. See https://www.winehq.org/pipermail/wine-devel/2019-November/154023.html for previous comments.

I'll try to run the tests on my Windows boxes in the next few days to see how much the results depend on driver behavior.

Stefan

[Vijay Kiran Kamuju]

Hi Stefan,

Thanks, a lot for pointing out the last review email.
I could not find it, will try to incorporate most of the comments.
Please do the other tests you mentioned.

Thanks,
Vijay

On Tue, Apr 7, 2020 at 6:14 PM Stefan Dösinger
<stefandoesinger(a)gmail.com> wrote:
> Hi Vijay,
>
> Halfway through reviewing this I couldn't help but have a dejavu feeling. See https://www.winehq.org/pipermail/wine-devel/2019-November/154023.html for previous comments.
>
> I'll try to run the tests on my Windows boxes in the next few days to see how much the results depend on driver behavior.
>
> Stefan