[1/2] opengl32/tests: Add tests for special case of SetPixelFormat

[Matijn Woudt]

I got confused by the relay logs earlier (they don't include the calls
to com objects), it's our implementation of IDirect3D9::CreateDevice
which is calling SetPixelFormat. The application calls CreateDevice
with focus_window a handle from GetDesktopWindow();

You're right that the game isn't actually drawing to this device, it
calls a few functions (see attached files) and then it releases this
device and creates a new one with an appropriate window for the game
itself.

There are currently no test cases for using a 'root_window'. What test
cases do you want to see? I can duplicate the current tests for use
with a root_window, but that's probably not what you want.

For the implementation, we might be able to detect this inside
CreateDevice, and skip the creation of a swapchain. Not sure if that's
a correct fix though.

Thanks again,

Matijn

On Mon, Nov 15, 2010 at 2:24 AM, Roderick Colenbrander
<thunderbird2k at gmail.com> wrote:
> It has been a while since I last looked at this area. The following
> bug came to my mind which is the same thing
> http://bugs.winehq.org/show_bug.cgi?id=9786
>
> I would start by figuring out for what purpose and for what calls the
> game is using GetDC(0). Turn on some d3d debug channels and try to
> figure that out. You might have to write some test cases (though they
> might exists already in d3d, but I haven't looked at the test in a
> while). I don't know for sure but can Direct3D actually render to the
> 'root_window'? I guess you can't ..
>
> Roderick
>
> On Sun, Nov 14, 2010 at 3:33 PM, Matijn Woudt <tijnema at gmail.com> wrote:
>> On Mon, Nov 15, 2010 at 12:06 AM, Roderick Colenbrander
>> <thunderbird2k at gmail.com> wrote:
>>> Hi Matijn,
>>>
>>> What 3D API is this game using? Is it using Direct3D or OpenGL?
>>>
>>> If it is Direct3D then I have the feeling the 'issue' is getting fixed
>>> in the wrong layer.
>>
>> It's using Direct3D, but I don't see how this can be fixed in Direct3D.
>>
>>>
>>> Further I'm not really sure whether we want to allow pixel format 1 to
>>> be used at all. In case of Wine all pixel formats are hardware
>>> accelerated (okay, the bitmaps one are set to indirect rendering so
>>> might be software based depending on the GLX implementation). On
>>> Windows you essentially have two GL implementations namely the
>>> Microsoft GDI renderer and the OpenGL ICD driver. The first several
>>> pixel formats are the ones from the software based GDI renderer...
>>>
>>> So even though Windows might allow setting pixel format 1 on HDC 0, I
>>> don't think it is the right thing to do.
>>>
>>> Roderick
>>
>> Not setting the pixel format (e.g. just returning TRUE) won't help the
>> game. Setting a different (hardware accelerated) format will probably
>> work, but that doesn't feel right. I'd really like to fix this bug,
>> but if the patch isn't right I don't have a clue how to fix it 'the
>> right way'.
>> Any hints?
>>
>> Thanks,
>>
>> Matijn
>>
>> ps. Trial for the game is available at:
>> http://www.sandlotgames.com/w5/hearts_medicine_season_1.html (200MB),
>> after installing run bin/prog.exe, launcher doesn't work.
>>>
>>> On Sun, Nov 14, 2010 at 9:55 AM, Matijn Woudt <tijnema at gmail.com> wrote:
>>>> Add tests for special case of SetPixelFormat
>>>>
>>>> Tests pass on my Windows XP laptop and Windows 7 PC.
>>>> The game 'Heart's Medicine Season One' depends on this behaviour.
>>>>
>>>>
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: calls
Type: application/octet-stream
Size: 5067 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20101118/941a859a/attachment.obj>