Re: [1/2] opengl32/tests: Add tests for special case of SetPixelFormat
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. 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 On Sun, Nov 14, 2010 at 9:55 AM, Matijn Woudt <tijnema(a)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.
On Mon, Nov 15, 2010 at 12:06 AM, Roderick Colenbrander <thunderbird2k(a)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(a)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.
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(a)gmail.com> wrote:
On Mon, Nov 15, 2010 at 12:06 AM, Roderick Colenbrander <thunderbird2k(a)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(a)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.
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(a)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(a)gmail.com> wrote:
On Mon, Nov 15, 2010 at 12:06 AM, Roderick Colenbrander <thunderbird2k(a)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(a)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.
On 18 November 2010 15:05, Matijn Woudt <tijnema(a)gmail.com> wrote:
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.
Swapchain creation isn't something you want to skip. Perhaps it's possible to delay GL context creation until something actually needs it though. I'm curious if things like DrawPrimitive() shouldn't fail anyway when the device is created with GetDesktopWindow() as window. Another option may be to allow the D3D context to be created, but immediately mark it invalid.
On Thu, Nov 18, 2010 at 3:35 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote:
On 18 November 2010 15:05, Matijn Woudt <tijnema(a)gmail.com> wrote:
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.
Swapchain creation isn't something you want to skip. Perhaps it's possible to delay GL context creation until something actually needs it though. I'm curious if things like DrawPrimitive() shouldn't fail anyway when the device is created with GetDesktopWindow() as window. Another option may be to allow the D3D context to be created, but immediately mark it invalid.
I gave the visual test suite a shot, normal test run on my Windows 7 x64: visual.c:196: Driver string: "atiumdag.dl visual.c:197: Description string: "ATI Ra visual.c:199: Device name string: "\\.\DI visual.c:201: Driver version 8.14.10.678 ---- visual: 5493 tests executed (0 marked as todo, 75 failures), 3 skipped. now, changing the code in create_window to return GetDesktopWindow(), gives visual.c:196: Driver string: "atiumdag.dl visual.c:197: Description string: "ATI Ra visual.c:199: Device name string: "\\.\DI visual.c:201: Driver version 8.14.10.678 ---- visual: 5493 tests executed (0 marked as todo, 75 failures), 3 skipped. There's only 1 difference, the first one really shows a window with all the triangle's, like it should. Second one doesn't show anything. So all the functions don't fail, they just don't seem to do anything.
Am Donnerstag 18 November 2010, 16:41:53 schrieb Matijn Woudt:
There's only 1 difference, the first one really shows a window with all the triangle's, like it should. Second one doesn't show anything. So all the functions don't fail, they just don't seem to do anything. I think we should set up the swapchain to use a dummy window, GL bitmap or WGL pbuffer and turn on render to fbo.
On Sat, Nov 20, 2010 at 3:17 AM, Stefan Dösinger <stefan(a)codeweavers.com> wrote:
Am Donnerstag 18 November 2010, 16:41:53 schrieb Matijn Woudt:
There's only 1 difference, the first one really shows a window with all the triangle's, like it should. Second one doesn't show anything. So all the functions don't fail, they just don't seem to do anything. I think we should set up the swapchain to use a dummy window, GL bitmap or WGL pbuffer and turn on render to fbo.
That's what I would suggest as well, but remove GL bitmap from the set of options. It means software GDI on windows and on Wine it means indirect rendering which can be bad. The pbuffer would be quite reliable but it is not around everywhere, if a dummy window works fine lets try that first. Roderick
On Sun, Nov 21, 2010 at 8:23 PM, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote:
On Sat, Nov 20, 2010 at 3:17 AM, Stefan Dösinger <stefan(a)codeweavers.com> wrote:
Am Donnerstag 18 November 2010, 16:41:53 schrieb Matijn Woudt:
There's only 1 difference, the first one really shows a window with all the triangle's, like it should. Second one doesn't show anything. So all the functions don't fail, they just don't seem to do anything. I think we should set up the swapchain to use a dummy window, GL bitmap or WGL pbuffer and turn on render to fbo.
That's what I would suggest as well, but remove GL bitmap from the set of options. It means software GDI on windows and on Wine it means indirect rendering which can be bad. The pbuffer would be quite reliable but it is not around everywhere, if a dummy window works fine lets try that first.
Roderick
I have created a patch that uses a dummy window. Please let me know if this is what you had in mind. It works for the game I created the original patch for. Matijn
On 23 November 2010 23:57, Matijn Woudt <tijnema(a)gmail.com> wrote:
I have created a patch that uses a dummy window. Please let me know if this is what you had in mind. It works for the game I created the original patch for.
The basic idea is similar, but it would have to be done in wined3d, and integrated with the rest of the context management. Look at e.g. context_update_window(), context_validate(), context_create() and WineD3D_CreateFakeGLContext().
On Wed, Nov 24, 2010 at 11:30 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote:
On 23 November 2010 23:57, Matijn Woudt <tijnema(a)gmail.com> wrote:
I have created a patch that uses a dummy window. Please let me know if this is what you had in mind. It works for the game I created the original patch for.
The basic idea is similar, but it would have to be done in wined3d, and integrated with the rest of the context management. Look at e.g. context_update_window(), context_validate(), context_create() and WineD3D_CreateFakeGLContext().
That's what I had in mind first too, but I couldn't figure out how to get that handle over to device_init (in d3d9) where the window is used too.
On 24 November 2010 23:34, Matijn Woudt <tijnema(a)gmail.com> wrote:
That's what I had in mind first too, but I couldn't figure out how to get that handle over to device_init (in d3d9) where the window is used too.
Why do you need it there?
On Wed, Nov 24, 2010 at 11:37 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote:
On 24 November 2010 23:34, Matijn Woudt <tijnema(a)gmail.com> wrote:
That's what I had in mind first too, but I couldn't figure out how to get that handle over to device_init (in d3d9) where the window is used too.
Why do you need it there?
The current code is using the window, I guess it wouldn't work if focus_window is still pointing to the main device context. I might be missing something here, but I don't see how this can possibly work.
participants (4)
-
Henri Verbeet -
Matijn Woudt -
Roderick Colenbrander -
Stefan Dösinger