January 2014 - Wine-Bugs - list.winehq.org

[Bug 2082] DirectDraw games only showing black screen
by wine-bugs＠winehq.org Jan. 9, 2014

Jan. 9, 2014

http://bugs.winehq.org/show_bug.cgi?id=2082 --- Comment #137 from Stefan Dösinger <stefan(a)codeweavers.com> --- (In reply to comment #136) > - The main thing I'm wondering about is if it wouldn't make more sense to > pass a window to wglCreateFullscreenDCWINE(). Some of the considerations > there are what should happen when the device window is e.g. destroyed or > minimized. Is there a device window in those ddraw cases? My impression is that SetCooperativeLevel(DDSCL_FULLSCREEN | DDSCL_EXCLUSIVE, hwnd_that_will_never_be_visible) sets the focus window, not the device window. It would be interesting what ddraw does when an application calls SetCooperativeLevel(DDSCL_SETDEVICEWINDOW, hwnd_that_will_never_be_visible). Similarly, what do d3d8/9 do when they are passed a window like the one Worms Armageddon uses? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 2082] DirectDraw games only showing black screen
by wine-bugs＠winehq.org Jan. 9, 2014

Jan. 9, 2014

http://bugs.winehq.org/show_bug.cgi?id=2082 --- Comment #136 from Henri Verbeet <hverbeet(a)gmail.com> --- (In reply to comment #135) > Created attachment 47154 [details] > Implement WGL extension to get fullscreen DC, use it in WineD3D > I think that mostly works for me, from a wined3d point of view. - The main thing I'm wondering about is if it wouldn't make more sense to pass a window to wglCreateFullscreenDCWINE(). Some of the considerations there are what should happen when the device window is e.g. destroyed or minimized. - If we do want to pass a device name to wglCreateFullscreenDCWINE(), it should probably take a WCHAR[], and you can get at that from the context as "context->swapchain->device->adapter->DeviceName". - wglDeleteFullscreenDCWINE() seems to just be a wrapper around DeleteDC(). If possible I think it would be preferable to be able to just call ReleaseDC() on the DC returned by wglCreateFullscreenDCWINE(), and then just use wined3d_release_dc(). - If we can just use wined3d_release_dc(), context->hdc_fullscreen can just go away, but otherwise it should probably be part of the other context bitfields like current/destroyed/valid. - When there are multiple threads drawing, wglCreateFullscreenDCWINE() is going to be called multiple times for the same window / display. I didn't really review the winemac.drv changes, but will it do the right thing in that case? wglGetFullscreenDCWINE() might be a more appropriate name for how we're using this. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 2082] DirectDraw games only showing black screen
by wine-bugs＠winehq.org Jan. 9, 2014

Jan. 9, 2014

http://bugs.winehq.org/show_bug.cgi?id=2082 Ken Thomases <ken(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #46977|0 |1 is obsolete| | --- Comment #135 from Ken Thomases <ken(a)codeweavers.com> --- Created attachment 47154 --> http://bugs.winehq.org/attachment.cgi?id=47154 Implement WGL extension to get fullscreen DC, use it in WineD3D (In reply to comment #132) I said (to Henri): > With respect to a WGL extension, were you thinking of something like an > alternative to wglMakeCurrent() such as wglMakeCurrentFullScreenWINE()? In looking at the code, I decided it makes more sense for the extension to provide a full-screen DC which can then be used pretty much as normal. The attached patch adds a Wine WGL extension named WGL_WINE_fullscreen_dc. It provides two functions: wglCreateFullscreenDCWINE() and wglDeleteFullscreenDCWINE(). The patch makes WineD3D aware of the extension and makes it use it instead of GetDC()/wined3d_release_dc() if the swapchain is not windowed. Then the extension is implemented in the Mac driver. Taken together, this gets Worms Armageddon to show its rendering without the use of any of its tweaks. Since the extension hasn't been implemented for the X11 driver it doesn't help there but, unlike my previous patch, it shouldn't break X11 either. It should work just like it has. If the extension is implemented for X11, then it should start working, too. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8320] DirectInput joystick timestamps are wrong
by wine-bugs＠winehq.org Jan. 8, 2014

Jan. 8, 2014

https://bugs.winehq.org/show_bug.cgi?id=8320 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |1.6.x -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 2082] DirectDraw games only showing black screen
by wine-bugs＠winehq.org Jan. 8, 2014

Jan. 8, 2014

http://bugs.winehq.org/show_bug.cgi?id=2082 arthur.huillet(a)free.fr changed: What |Removed |Added ---------------------------------------------------------------------------- CC|arthur.huillet(a)free.fr | -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 2082] DirectDraw games only showing black screen
by wine-bugs＠winehq.org Jan. 8, 2014

Jan. 8, 2014

http://bugs.winehq.org/show_bug.cgi?id=2082 --- Comment #134 from Henri Verbeet <hverbeet(a)gmail.com> --- (In reply to comment #133) > Created attachment 47148 [details] > Test z-order in ddraw tests > > To my surprise, SetForegroundWindow() has nothing to do with z-order, at > all. It just affects foreground/active statuses which are related to focus. > > This patch modifies the ddraw tests to check z-order. In all of the places > that used to call SetForegroundWindow(), I now also call SetWindowPos(…, > HWND_TOP, …). In all of the places that checked the window returned from > GetForegroundWindow(), I now also check the window order. I also check the > z-order immediately after attempting to set it to verify that it's working. > We don't want new tests to go anywhere that isn't ddraw[1247].c. (And the existing ones should get cleaned up and moved over to there eventually as well.) > The tests marked "todo_wine" in testcooperativelevels_normal() are due to > ddraw/wined3d setting the window topmost for fullscreen and, in some cases, > not restoring it. > Right, setting WS_EX_TOPMOST is correct for d3d8 and d3d9, it isn't for ddraw. (See also the various versions of test_window_style().) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 2082] DirectDraw games only showing black screen
by wine-bugs＠winehq.org Jan. 8, 2014

Jan. 8, 2014

http://bugs.winehq.org/show_bug.cgi?id=2082 --- Comment #132 from Ken Thomases <ken(a)codeweavers.com> --- (In reply to comment #131) > We also have tests that show that switching to fullscreen does have an effect > on e.g. window dimensions, z-order and focus. I found tests for the foreground window in dlls/ddraw/tests/ddrawmodes.c, testcooperativelevels_normal() and testcooperativelevels_exclusive(). I didn't find other tests related to z-order. Please let me know if I missed them. As we've seen with this bug, a window may be the foreground window without being front-most, in particular if it owns other windows. Also if it's non-topmost and there are topmost windows. I'll try to extend the tests to test some possibilities with respect to actual z-order viz-a-viz owned, topmost, and other windows. With respect to a WGL extension, were you thinking of something like an alternative to wglMakeCurrent() such as wglMakeCurrentFullScreenWINE()? --- Comment #133 from Ken Thomases <ken(a)codeweavers.com> --- Created attachment 47148 --> http://bugs.winehq.org/attachment.cgi?id=47148 Test z-order in ddraw tests To my surprise, SetForegroundWindow() has nothing to do with z-order, at all. It just affects foreground/active statuses which are related to focus. This patch modifies the ddraw tests to check z-order. In all of the places that used to call SetForegroundWindow(), I now also call SetWindowPos(…, HWND_TOP, …). In all of the places that checked the window returned from GetForegroundWindow(), I now also check the window order. I also check the z-order immediately after attempting to set it to verify that it's working. The tests marked "todo_wine" in testcooperativelevels_normal() are due to ddraw/wined3d setting the window topmost for fullscreen and, in some cases, not restoring it. For testcooperativelevels_exclusive(), I make sure neither window is topmost before proceeding. I also create two other windows, one topmost and one owned by the main window. I test that both remain in front of the main window even when it's fullscreen. Wine keeps the owned one in front (which is at the root of this bug) but, as expected, promotes the main window to topmost, bringing it in front of the other topmost window, when it shouldn't. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 9095] ITypeInfo_fnInvoke failed to convert param 1 to VT_VARIANT|VT_ARRAY|VT_BYREF from VT_I2|VT_BYREF
by wine-bugs＠winehq.org Jan. 7, 2014

Jan. 7, 2014

http://bugs.winehq.org/show_bug.cgi?id=9095 --- Comment #7 from Bruno Jesus <00cpxxx(a)gmail.com> --- Still in wine 1.7.10. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 9127] Games video movies are not playable
by wine-bugs＠winehq.org Jan. 7, 2014

Jan. 7, 2014

http://bugs.winehq.org/show_bug.cgi?id=9127 hibi.sasahara(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hibi.sasahara(a)gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 34381] New: Rectangle rotation problem using GM_ADVANCED graphicmode
by wine-bugs＠winehq.org Jan. 7, 2014

Jan. 7, 2014

http://bugs.winehq.org/show_bug.cgi?id=34381 Bug #: 34381 Summary: Rectangle rotation problem using GM_ADVANCED graphicmode Product: Wine Version: 1.6 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: gdi32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: ralf.habacker(a)freenet.de Classification: Unclassified Created attachment 45766 --> http://bugs.winehq.org/attachment.cgi?id=45766 Wine Screenshot Drawing a rotated rectangle with GM_ADVANDED graphicmode do not display a rotated rectangle. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

1 15