https://bugs.winehq.org/show_bug.cgi?id=37398
Bug ID: 37398 Summary: Urban Assault black screen when using software renderer and DDSCAPS_SYSTEMMEMORY Product: Wine Version: 1.7.17 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs@winehq.org Reporter: erich.e.hoover@gmail.com Depends on: 37307 Regression SHA1: b464067313bff1fd9a25b284b48a252025c4504f Distribution: ---
Created attachment 49735 --> https://bugs.winehq.org/attachment.cgi?id=49735 Workaround
Once Bug #37307 is resolved then Urban Assault runs into another issue (at least, when using the software renderer). The game has a black screen and just hangs there, apparently due to an unexpected DDSCAPS_SYSTEMMEMORY capability being set. Workaround attached.
Note: This commit is later moved (commit 9443c95a895a530fdbbb607758f674467e2010c7), but the issue persists.
https://bugs.winehq.org/show_bug.cgi?id=37398
Stefan Dösinger stefan@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefan@codeweavers.com
--- Comment #1 from Stefan Dösinger stefan@codeweavers.com --- Is it creating a P8 surface?
https://bugs.winehq.org/show_bug.cgi?id=37398
Erich Hoover erich.e.hoover@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|1.7.17 |1.7.28 Distribution|--- |Ubuntu
https://bugs.winehq.org/show_bug.cgi?id=37398
--- Comment #2 from Erich Hoover erich.e.hoover@gmail.com --- (In reply to Stefan Dösinger from comment #1)
Is it creating a P8 surface?
Yes
https://bugs.winehq.org/show_bug.cgi?id=37398
Erich Hoover erich.e.hoover@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |37399
https://bugs.winehq.org/show_bug.cgi?id=37398
Erich Hoover erich.e.hoover@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
https://bugs.winehq.org/show_bug.cgi?id=37398
--- Comment #3 from Erich Hoover erich.e.hoover@gmail.com --- Whoops, forgot to put the console output: fixme:d3d_surface:surface_convert_format Cannot find a conversion function from format WINED3DFMT_P8_UINT to WINED3DFMT_B5G6R5_UNORM.
https://bugs.winehq.org/show_bug.cgi?id=37398
--- Comment #4 from Erich Hoover erich.e.hoover@gmail.com --- WINEDEBUG="+ddraw,+d3d_surface" log: https://dl.dropboxusercontent.com/u/195059/wine/logs/bug37398.log
https://bugs.winehq.org/show_bug.cgi?id=37398
--- Comment #5 from Erich Hoover erich.e.hoover@gmail.com --- Created attachment 49738 --> https://bugs.winehq.org/attachment.cgi?id=49738 WINEDEBUG="+ddraw,+d3d_surface" log
Disregard comment #4, use attachment instead.
https://bugs.winehq.org/show_bug.cgi?id=37398
--- Comment #6 from Stefan Dösinger stefan@codeweavers.com --- warn:d3d_surface:surface_blt_special Src is in sysmem, rejecting gl blt
This is why the system memory location matters. But I think the attempt to perform this blit is already a bug. The destination is the real frontbuffer, and it has the format R5G6B5 even though the display mode is P8.
The log is from an older wine version. Is there a chance you can deal with bug #37307 without using an older revision?
As far as I can see wined3d_device_reset is never called because the frontbuffer created by the application (0x186028 / 0x158f70) predates the mode change. (Actually, it predates two mode changes, from P8 to R5G6B5 and back again.)
https://bugs.winehq.org/show_bug.cgi?id=37398
--- Comment #7 from Erich Hoover erich.e.hoover@gmail.com --- (In reply to Stefan Dösinger from comment #6)
... The log is from an older wine version. Is there a chance you can deal with bug #37307 without using an older revision? ...
Sorry I didn't state this earlier, the log is from the commit just prior to 9d49b7a9be6d4ed59a69c3453de4eadb0101ea09 (b6efe8c9c1e881aa3b03e282183f2e9546b480b4) to avoid running into Bug #37399. I have a fix for Bug #37307 (http://source.winehq.org/patches/data/107036), so that doesn't stop me from testing on newer versions.
https://bugs.winehq.org/show_bug.cgi?id=37398
Erich E. Hoover erich.e.hoover@wine-staging.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #49735|0 |1 is obsolete| |
--- Comment #8 from Erich E. Hoover erich.e.hoover@wine-staging.com --- Created attachment 51742 --> https://bugs.winehq.org/attachment.cgi?id=51742 wined3d: Report blitter support for 8-bit palettized surfaces.
The attached mbox patch (against current git) fixes this bug for me. Stefan, when you have a chance could you take a look at this and see if this is a good solution? It's also necessary to fix Bug #37399 to completely resolve the issue (you will still see a black screen unless you also apply that patch).
https://bugs.winehq.org/show_bug.cgi?id=37398 Bug 37398 depends on bug 37307, which changed state.
Bug 37307 Summary: Urban Assault black screen when using software renderer (incorrect device enumeration order) https://bugs.winehq.org/show_bug.cgi?id=37307
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
https://bugs.winehq.org/show_bug.cgi?id=37398
--- Comment #9 from Stefan Dösinger stefan@codeweavers.com --- Hmm, it sounds like the game wants palettized blits to just pass data from src to dst surface without doing any palette lookup or other conversions. But I think this is what the current code should already do.
Can you check what the format of the destination surface is in the affected blits?
https://bugs.winehq.org/show_bug.cgi?id=37398
--- Comment #10 from Erich E. Hoover erich.e.hoover@wine-staging.com --- (In reply to Stefan Dösinger from comment #9)
Hmm, it sounds like the game wants palettized blits to just pass data from src to dst surface without doing any palette lookup or other conversions. But I think this is what the current code should already do.
Can you check what the format of the destination surface is in the affected blits?
This is actually to get the primary surface to work, without the patch (on current git) I get: fixme:d3d_surface:surface_convert_format Cannot find a conversion function from format WINED3DFMT_P8_UINT to WINED3DFMT_B5G6R5_UNORM.
https://bugs.winehq.org/show_bug.cgi?id=37398
Stefan Dösinger stefandoesinger@gmx.at changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|stefan@codeweavers.com |stefandoesinger@gmx.at
https://bugs.winehq.org/show_bug.cgi?id=37398
super_man@post.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |super_man@post.com
https://bugs.winehq.org/show_bug.cgi?id=37398
Sergey Isakov isakov-sl@bk.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |isakov-sl@bk.ru
--- Comment #11 from Sergey Isakov isakov-sl@bk.ru --- Is it correct link to download? http://www.old-games.ru/game/download/560.html
https://bugs.winehq.org/show_bug.cgi?id=37398
--- Comment #12 from Sergey Isakov isakov-sl@bk.ru --- (In reply to Erich E. Hoover from comment #10)
This is actually to get the primary surface to work, without the patch (on current git) I get: fixme:d3d_surface:surface_convert_format Cannot find a conversion function from format WINED3DFMT_P8_UINT to WINED3DFMT_B5G6R5_UNORM.
Implementing this conversion I got the game somehow working in software mode. ~~~~ static void convert_p8_r5g6b5(const BYTE *src, BYTE *dst, DWORD src_pitch, DWORD dst_pitch, unsigned int width, unsigned int height, const struct wined3d_palette *palette) { unsigned int x, y; const BYTE *src_row; WORD *dst_row; WORD grey = 0x0821;
for (y = 0; y < height; ++y) { src_row = &src[src_pitch * y]; dst_row = (WORD *)&dst[dst_pitch * y]; for (x = 0; x < width; ++x) { BYTE src_color = src_row[x]; if (palette) { dst_row[x] = (palette->colors[src_color].rgbRed << 11) | (palette->colors[src_color].rgbGreen << 5) | palette->colors[src_color].rgbBlue; } else { dst_row[x] = grey * src_color; } } } } ~~~~
https://bugs.winehq.org/show_bug.cgi?id=37398
--- Comment #13 from Erich E. Hoover erich.e.hoover@wine-staging.com --- (In reply to Sergey Isakov from comment #12)
... Implementing this conversion I got the game somehow working in software mode. ...
Wow, can you submit this officially and see what the DX devs have to say? ( https://wiki.winehq.org/Submitting_Patches )
https://bugs.winehq.org/show_bug.cgi?id=37398
--- Comment #14 from Sergey Isakov isakov-sl@bk.ru --- (In reply to Erich E. Hoover from comment #13)
(In reply to Sergey Isakov from comment #12)
... Implementing this conversion I got the game somehow working in software mode. ...
Wow, can you submit this officially and see what the DX devs have to say? ( https://wiki.winehq.org/Submitting_Patches )
I can but the patch requires significant changes in other conversion functions. I will try.
https://bugs.winehq.org/show_bug.cgi?id=37398
--- Comment #15 from Sergey Isakov isakov-sl@bk.ru --- Created attachment 53660 --> https://bugs.winehq.org/attachment.cgi?id=53660 It works
https://bugs.winehq.org/show_bug.cgi?id=37398
--- Comment #16 from Erich E. Hoover erich.e.hoover@wine-staging.com --- (In reply to Sergey Isakov from comment #14)
... I can but the patch requires significant changes in other conversion functions. I will try.
If there's anything that I can do to help then please let me know.
https://bugs.winehq.org/show_bug.cgi?id=37398
--- Comment #17 from Stefan Dösinger stefandoesinger@gmx.at --- I am writing this from memory, so please bear with me...
Afair converting P8->RGB on blit is wrong, and we have a test showing that. The real problem here is that a surface isn't marked lost correctly here on a mode change. The application should recreate it or restore it to give it a RGB16 color format instead of P8.
Henri recently made improvements to handling of lost surfaces in ddraw. Maybe it's easier to handle this now.
https://bugs.winehq.org/show_bug.cgi?id=37398
--- Comment #18 from Henri Verbeet hverbeet@gmail.com --- (In reply to Stefan Dösinger from comment #17)
Afair converting P8->RGB on blit is wrong, and we have a test showing that. The real problem here is that a surface isn't marked lost correctly here on a mode change. The application should recreate it or restore it to give it a RGB16 color format instead of P8.
Henri recently made improvements to handling of lost surfaces in ddraw. Maybe it's easier to handle this now.
If the ddraw object is in the exclusive cooperative level surfaces should get marked as lost correctly on mode changes. If it isn't, we never get the notification because we don't call wined3d_device_acquire_focus_window(). (And can't, at least not on the window passed to SetCooperativeLevel().)
https://bugs.winehq.org/show_bug.cgi?id=37398
--- Comment #19 from Henri Verbeet hverbeet@gmail.com --- I have a patch for this and the related bug 37399.
Unfortunately it seems I can't attach patches to bugzilla for testing without risking them getting "STAGED", so I won't.
https://bugs.winehq.org/show_bug.cgi?id=37398
--- Comment #20 from Sergey Isakov isakov-sl@bk.ru --- If the patch is useful for mainstream then we waiting it soon. If it is a hack then let it be staged! :)
https://bugs.winehq.org/show_bug.cgi?id=37398
winetest@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winetest@luukku.com
--- Comment #21 from winetest@luukku.com --- (In reply to Sergey Isakov from comment #20)
If the patch is useful for mainstream then we waiting it soon. If it is a hack then let it be staged! :)
Can you test wine 2.0rc5? Depends and blocks bugs are marked fixed and something towards this was committed too.
https://bugs.winehq.org/show_bug.cgi?id=37398
--- Comment #22 from Sergey Isakov isakov-sl@bk.ru --- Created attachment 56845 --> https://bugs.winehq.org/attachment.cgi?id=56845 Works fine
Tested with wine-2.0-rc4-80-gacd6234 Looks fine. I see no problems at all.
https://bugs.winehq.org/show_bug.cgi?id=37398
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
https://bugs.winehq.org/show_bug.cgi?id=37398
--- Comment #23 from Erich E. Hoover erich.e.hoover@wine-staging.com --- (In reply to Sergey Isakov from comment #22)
Created attachment 56845 [details] Works fine
Tested with wine-2.0-rc4-80-gacd6234 Looks fine. I see no problems at all.
This bug is for the software renderer. To change the renderer after install you need to edit "ENV/guid3d.def", for the software renderer this should contain: <software> and for accelerated rendering it should contain: <primary>
https://bugs.winehq.org/show_bug.cgi?id=37398
--- Comment #24 from Sergey Isakov isakov-sl@bk.ru --- (In reply to Erich E. Hoover from comment #23)
(In reply to Sergey Isakov from comment #22)
Created attachment 56845 [details] Works fine
Tested with wine-2.0-rc4-80-gacd6234 Looks fine. I see no problems at all.
This bug is for the software renderer. To change the renderer after install you need to edit "ENV/guid3d.def", for the software renderer this should contain:
<software> and for accelerated rendering it should contain: <primary>
OK. If I edit this to <software> I got only black screen. ---- fixme:d3d:surface_cpu_blt Filter WINED3D_TEXF_LINEAR not supported in software blit.
https://bugs.winehq.org/show_bug.cgi?id=37398
--- Comment #25 from Erich E. Hoover erich.e.hoover@wine-staging.com --- (In reply to Sergey Isakov from comment #24)
... OK. If I edit this to <software> I got only black screen.
fixme:d3d:surface_cpu_blt Filter WINED3D_TEXF_LINEAR not supported in software blit.
I have attached a hack to Bug #37399 (attachment 56842) that works around this issue (and that issue), I'm hoping that it narrows things down enough that Henri can create a fix for the problem.
https://bugs.winehq.org/show_bug.cgi?id=37398
--- Comment #26 from Henri Verbeet hverbeet@gmail.com --- (In reply to Erich E. Hoover from comment #25)
I have attached a hack to Bug #37399 (attachment 56842 [details]) that works around this issue (and that issue), I'm hoping that it narrows things down enough that Henri can create a fix for the problem.
Well, it works for me. I suspect the fix for bug 37399 doesn't work for you because the hack you're using for this one isn't quite right, e.g. because it depends on the surface getting lost to set/reset the palette, but we'll just have to wait and see after Wine 2.0.
https://bugs.winehq.org/show_bug.cgi?id=37398
--- Comment #27 from Erich E. Hoover erich.e.hoover@wine-staging.com --- (In reply to Henri Verbeet from comment #26)
... Well, it works for me. I suspect the fix for bug 37399 doesn't work for you because the hack you're using for this one isn't quite right, e.g. because it depends on the surface getting lost to set/reset the palette, but we'll just have to wait and see after Wine 2.0.
Sounds like a plan, I'll look forward to testing when you're ready.
https://bugs.winehq.org/show_bug.cgi?id=37398
--- Comment #28 from Henri Verbeet hverbeet@gmail.com --- How does this work with Wine 2.1?
https://bugs.winehq.org/show_bug.cgi?id=37398
Erich E. Hoover erich.e.hoover@wine-staging.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #29 from Erich E. Hoover erich.e.hoover@wine-staging.com --- (In reply to Henri Verbeet from comment #28)
How does this work with Wine 2.1?
Looks like it's working great, thanks Henri!