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

2010-11-24 Thread Henri Verbeet
On 23 November 2010 23:57, Matijn Woudt tijn...@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().




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

2010-11-24 Thread Matijn Woudt
On Wed, Nov 24, 2010 at 11:30 PM, Henri Verbeet hverb...@gmail.com wrote:
 On 23 November 2010 23:57, Matijn Woudt tijn...@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.




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

2010-11-24 Thread Henri Verbeet
On 24 November 2010 23:34, Matijn Woudt tijn...@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?




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

2010-11-24 Thread Matijn Woudt
On Wed, Nov 24, 2010 at 11:37 PM, Henri Verbeet hverb...@gmail.com wrote:
 On 24 November 2010 23:34, Matijn Woudt tijn...@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.




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

2010-11-23 Thread Matijn Woudt
On Sun, Nov 21, 2010 at 8:23 PM, Roderick Colenbrander
thunderbir...@gmail.com wrote:
 On Sat, Nov 20, 2010 at 3:17 AM, Stefan Dösinger ste...@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
From 9fa163c4f47355fc3f4940e1c966aa93ba0c64e3 Mon Sep 17 00:00:00 2001
From: Matijn Woudt tijn...@gmail.com
Date: Tue, 23 Nov 2010 23:51:06 +0100
Subject: d3d9: Create dummy window if focus window is the desktop window

---
 dlls/d3d9/Makefile.in|2 +-
 dlls/d3d9/d3d9_private.h |2 ++
 dlls/d3d9/device.c   |   12 
 3 files changed, 15 insertions(+), 1 deletions(-)

diff --git a/dlls/d3d9/Makefile.in b/dlls/d3d9/Makefile.in
index 9d5a4d8..ed949d3 100644
--- a/dlls/d3d9/Makefile.in
+++ b/dlls/d3d9/Makefile.in
@@ -1,6 +1,6 @@
 MODULE= d3d9.dll
 IMPORTLIB = d3d9
-IMPORTS   = dxguid uuid wined3d
+IMPORTS   = dxguid uuid wined3d user32
 
 C_SRCS = \
buffer.c \
diff --git a/dlls/d3d9/d3d9_private.h b/dlls/d3d9/d3d9_private.h
index 02f9c20..7d8d45e 100644
--- a/dlls/d3d9/d3d9_private.h
+++ b/dlls/d3d9/d3d9_private.h
@@ -178,6 +178,8 @@ typedef struct IDirect3DDevice9Impl
 unsigned int numConvertedDecls, declArraySize;
 
 BOOL  notreset;
+
+HWND  dummy_window;
 } IDirect3DDevice9Impl;
 
 HRESULT device_init(IDirect3DDevice9Impl *device, IWineD3D *wined3d, UINT 
adapter, D3DDEVTYPE device_type,
diff --git a/dlls/d3d9/device.c b/dlls/d3d9/device.c
index 349bde4..ddf431d 100644
--- a/dlls/d3d9/device.c
+++ b/dlls/d3d9/device.c
@@ -275,6 +275,7 @@ static ULONG WINAPI DECLSPEC_HOTPATCH 
IDirect3DDevice9Impl_Release(LPDIRECT3DDEV
   IWineD3DDevice_ReleaseFocusWindow(This-WineD3DDevice);
   IWineD3DDevice_Release(This-WineD3DDevice);
   wined3d_mutex_unlock();
+  if(This-dummy_window) DestroyWindow(This-dummy_window);
 
   HeapFree(GetProcessHeap(), 0, This);
 }
@@ -3255,6 +3256,17 @@ HRESULT device_init(IDirect3DDevice9Impl *device, 
IWineD3D *wined3d, UINT adapte
 device-device_parent_vtbl = d3d9_wined3d_device_parent_vtbl;
 device-ref = 1;
 
+if(focus_window == GetDesktopWindow()) {
+WNDCLASSA wc = {0};
+wc.lpfnWndProc = DefWindowProcA;
+wc.lpszClassName = wine_d3d9_dummy_window;
+RegisterClassA(wc);
+
+focus_window = CreateWindowA(wine_d3d9_dummy_window, 
wine_d3d9_dummy_window, WS_POPUP, 0, 0, 640, 480, 0, 0, 0, 0);
+parameters-hDeviceWindow = focus_window;
+device-dummy_window = focus_window;
+}
+
 if (!(flags  D3DCREATE_FPU_PRESERVE)) setup_fpu();
 
 wined3d_mutex_lock();
-- 
1.7.0.4




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

2010-11-21 Thread Roderick Colenbrander
On Sat, Nov 20, 2010 at 3:17 AM, Stefan Dösinger ste...@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




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

2010-11-20 Thread Stefan Dösinger
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.


signature.asc
Description: This is a digitally signed message part.



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

2010-11-18 Thread 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
thunderbir...@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 tijn...@gmail.com wrote:
 On Mon, Nov 15, 2010 at 12:06 AM, Roderick Colenbrander
 thunderbir...@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 tijn...@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.









calls
Description: Binary data



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

2010-11-18 Thread Henri Verbeet
On 18 November 2010 15:05, Matijn Woudt tijn...@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.




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

2010-11-18 Thread Matijn Woudt
On Thu, Nov 18, 2010 at 3:35 PM, Henri Verbeet hverb...@gmail.com wrote:
 On 18 November 2010 15:05, Matijn Woudt tijn...@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.




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

2010-11-14 Thread Roderick Colenbrander
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 tijn...@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.








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

2010-11-14 Thread Matijn Woudt
On Mon, Nov 15, 2010 at 12:06 AM, Roderick Colenbrander
thunderbir...@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 tijn...@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.









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

2010-11-14 Thread Roderick Colenbrander
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 tijn...@gmail.com wrote:
 On Mon, Nov 15, 2010 at 12:06 AM, Roderick Colenbrander
 thunderbir...@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 tijn...@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.