http://bugs.winehq.org/show_bug.cgi?id=13954
Summary: Only top half of screen visible Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: michael@araneidae.co.uk
Created an attachment (id=14107) --> (http://bugs.winehq.org/attachment.cgi?id=14107) In game menu with only half of screen covered.
For this bug report I'll concentrate on Thief (The Dark Project), but I'm seeing this problem in a lot of places. In brief, only the top half of the screen is visible in certain graphical modes.
In more detail: Thief seems to use four different graphical modes, each with different behaviour.
1. The first mode, used for the menu screens on entry to the game, work normally. I'm doing this test with a wine virtual desktop at 640x480 resolution (and my real desktop is 1280x1024).
2. On entry to the game it uses hardware 3d graphics that runs very slowly. This seems to be a known problem with Thief, though I can't see a bug report for this.
3. Hitting ESC brings up the in-game menu which normally replaces the entire display; in this report only just under the top half the screen is visible. Fortunately I can see just enough of the configuration menu to select software 3d graphics.
4. Software 3d graphics used to work tolerably (in a somewhat earlier release, maybe 0.9.59?), but now I see only the top quarter or less of the screen!
I'll try and attach some screenshots to illustrate this. Um -- how am I supposed to add more than one screenshot in this message? I've attached an example for case (3).
This is with Wine 1.0-rc5 built from git, but I've been seeing this problem for a while now.
http://bugs.winehq.org/show_bug.cgi?id=13954
--- Comment #1 from Michael Abbott michael@araneidae.co.uk 2008-06-16 12:54:04 --- Created an attachment (id=14108) --> (http://bugs.winehq.org/attachment.cgi?id=14108) Only top quarter or less of screen updated in software 3D mode
This image shows how the top quarter of the screen updates with software 3D mode selected, but the rest of the screen remains as show by previous modes.
http://bugs.winehq.org/show_bug.cgi?id=13954
--- Comment #2 from Michael Abbott michael@araneidae.co.uk 2008-06-20 08:35:53 --- Same problem with Thief 2, the in-game menu doesn't display correctly in the same way.
http://bugs.winehq.org/show_bug.cgi?id=13954
--- Comment #3 from Michael Abbott michael@araneidae.co.uk 2008-06-20 08:37:49 --- Created an attachment (id=14208) --> (http://bugs.winehq.org/attachment.cgi?id=14208) In game menu for Thief II with only half of menu visible
This is pretty identical to Thief 1, though unfortunately in this case the video option part of the screen is inaccessible, so I can't try changing settings.
http://bugs.winehq.org/show_bug.cgi?id=13954
--- Comment #4 from Michael Abbott michael@araneidae.co.uk 2008-06-20 09:50:50 --- Created an attachment (id=14209) --> (http://bugs.winehq.org/attachment.cgi?id=14209) Partial view of Splinter Cell screen
This screenshot was taken after the cut scene between two levels of Splinter Cell (the video in the cut scenes does not play correctly), and shows only a quarter of the proper screen. Note that on restarting the game the full screen is shown correctly (well, as correctly as Splinter Cell plays, which isn't very).
http://bugs.winehq.org/show_bug.cgi?id=13954
--- Comment #5 from Lei Zhang thestig@google.com 2008-06-24 22:53:59 --- What video card / driver version are you using? Is there a demo for any of these games that show the same problem?
http://bugs.winehq.org/show_bug.cgi?id=13954
--- Comment #6 from Michael Abbott michael@araneidae.co.uk 2008-06-27 11:28:54 --- (In reply to comment #5)
What video card / driver version are you using?
My system is Ubuntu 8.04 with an ATI Radeon X1650 card with the xorg-driver-fglrx driver, version 1:7.1.0-8-3+2.6.24.12-16.34
Is there a demo for any of these games that show the same problem?
http://files.filefront.com/Thief+The+Dark+Project+Demo+Baffords+Manor/;51086... seems to be a demo for Thief 1 (first level). Even better: it actually works and shows both the problems I reported perfectly.
http://bugs.winehq.org/show_bug.cgi?id=13954
Lei Zhang thestig@google.com changed:
What |Removed |Added ---------------------------------------------------------------------------- URL| |http://files.filefront.com/T | |hief+The+Dark+Project+Demo+B | |affords+Manor/;5108626;/file | |info.html Keywords| |download
http://bugs.winehq.org/show_bug.cgi?id=13954
--- Comment #7 from Michael Abbott michael@araneidae.co.uk 2008-06-27 12:54:21 --- There is a Thief II demo at http://downloads.gamezone.com/demos/d1353.htm -- it also shows the same problem.
http://bugs.winehq.org/show_bug.cgi?id=13954
Alexander Dorofeyev alexd4@inbox.lv changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |alexd4@inbox.lv
--- Comment #8 from Alexander Dorofeyev alexd4@inbox.lv 2008-06-27 13:57:11 --- Works great for the most part on Nvidia except known video intro/cutscene bug. Doesn't seem slow either (I use hardware ON). What render target lock modes have you tried? Looking glass games like Thief, System Shock 2 menu drawing is all pretty much render target locking over and over. Another thing to try is disabling pixel buffer object extension (hacking dlls/wined3d/directx.c). I think this is most likely broken ATI driver though.
http://bugs.winehq.org/show_bug.cgi?id=13954
--- Comment #9 from Alexander Dorofeyev alexd4@inbox.lv 2008-06-27 14:05:29 --- Also, just FIY, if you use default Wine settings without DirectDrawRenderer=opengl override, when you get into the menu after starting Thief, wine is using gdi to draw at that moment. Wine will only reset to using opengl (which, aparently, is broken) after you enter the 3D game. You can save yourself some time when testing by settings DirectDrawRenderer=opengl. Then you have to see the problem right from the start.
http://bugs.winehq.org/show_bug.cgi?id=13954
--- Comment #10 from Michael Abbott michael@araneidae.co.uk 2008-06-27 14:07:44 --- Interesting. The cut scene videos in "Splinter Cell" show the same effect of only displaying on the top quarter of the screen, the rest of the screen is left black -- and then when the next scene of the game begins the image is in the top left hand quarter.
http://bugs.winehq.org/show_bug.cgi?id=13954
--- Comment #11 from Michael Abbott michael@araneidae.co.uk 2008-06-27 14:14:44 --- (In reply to comment #9)
Also, just FIY, if you use default Wine settings without DirectDrawRenderer=opengl override, when you get into the menu after starting Thief, wine is using gdi to draw at that moment. Wine will only reset to using opengl (which, aparently, is broken) after you enter the 3D game. You can save yourself some time when testing by settings DirectDrawRenderer=opengl. Then you have to see the problem right from the start.
YES! I've just added that option, and run up the Thief 1 demo (just after playing Splinter Cell) and the screen I get is very interesting: I'll do an attachment in a moment -- the top half is the Thief startup screen, and the bottom is part of the Splinter Cell menu screen!
opengl is broken? Yes, that could cause problems ... ;) Any relevant links on this?
http://bugs.winehq.org/show_bug.cgi?id=13954
--- Comment #12 from Michael Abbott michael@araneidae.co.uk 2008-06-27 14:16:52 --- Created an attachment (id=14397) --> (http://bugs.winehq.org/attachment.cgi?id=14397) Thief 1 running with opengl mode selected on startup
The top half of the screen shows the top half of the Thief 1 initial menu screen, the bottom half shows a left over screen from an earlier game.
http://bugs.winehq.org/show_bug.cgi?id=13954
Michael Abbott michael@araneidae.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |michael@araneidae.co.uk
--- Comment #13 from Alexander Dorofeyev alexd4@inbox.lv 2008-06-27 15:06:43 --- (In reply to comment #11)
(In reply to comment #9) opengl is broken? Yes, that could cause problems ... ;) Any relevant links on this?
All I meant is that graphics rendered through opengl, as opposed to gdi backend, are broken. The only functionality that Thief and some other Looking Glass games use in menu is called render target locking in wine's lingo and controlled using RenderTargetLockMode key (pixel buffer object opengl extension also may influence how well or how bad it works, but it can only be disabled by hacking source AFAIK).
I don't know much about Splinter Cell, but it's very possible that it also uses RT locking for drawing videos, that's how it's done in some other games too.
--- Comment #14 from Michael Abbott michael@araneidae.co.uk 2008-06-29 09:46:26 ---
All I meant is that graphics rendered through opengl, as opposed to gdi backend, are broken.
Is this a recorded Wine bug? If so, presumably this bug should be reported as a duplicate of the corresponding Wine/opengl bug.
I would say that several OpenGL only games play just fine with my graphics card + driver, so I'm presuming that the problem isn't fundamental to the graphics card. I've had perfect or nearly play from the following: Alice (McGee's), Max Payne (I), Project Eden, Return to Castle Wolfenstein, Deus Ex, Hitman (nasty game), UT2004 (Linux install), so to say my card/driver is broken seems evasive; though it has to be said that the list of miserable failures is quite a lot longer...
Can confirm that the bug remains unchanged with Wine 1.1.0, and I'm actually pretty sure it's a regression.
Oh, I should probably paste in the log from my most recent run of the Thief 1 demo (it's only six lines, so I won't make an attachment):
fixme:mixer:ALSA_MixerInit No master control found on MPU-401 UART, disabling mixer fixme:win:EnumDisplayDevicesW ((null),0,0x33f868,0x00000000), stub! fixme:d3d:test_pbo_functionality >>>>>>>>>>>>>>>>> GL_INVALID_OPERATION (0x502) from Loading the PBO test texture @ directx.c / 3563 fixme:x11drv:X11DRV_desktop_SetCurrentMode Cannot change screen BPP from 32 to 16 fixme:d3d:WineD3D_ChoosePixelFormat Add OpenGL context recreation support to SetDepthStencilSurface err:d3d:WineD3D_ChoosePixelFormat Can't find a suitable iPixelFormat fixme:d3d:WineD3D_ChoosePixelFormat Add OpenGL context recreation support to SetDepthStencilSurface
Unfortunately I've no idea what render target locking is (Google suggests to me that it's a Direct3D feature that Wine's had problems with in the past), and I'm not a graphics programmer (I tend to deal with embedded systems instead). Can we pin this issue down to either a Wine specific bug or a particular ATI driver bug?
The bug is completely and rapidly reproducible (it'd be nice if somebody else with an ATI card could confirm -- it bugs me seeing my bugs left as "unconfirmed", except when they're crap).
http://bugs.winehq.org/show_bug.cgi?id=13954
--- Comment #15 from Alexander Dorofeyev alexd4@inbox.lv 2008-06-29 10:44:23 --- (In reply to comment #14)
Is this a recorded Wine bug? If so, presumably this bug should be reported as a duplicate of the corresponding Wine/opengl bug.
Uh, no, I wasn't referring to anything in particular besides the obvious. Just saying that apparently gdi way of doing this works but opengl doesn't (for whatever reason), so you can test with DirectDrawRenderer=opengl to see the problem immediately in games like Thief.
Unfortunately I've no idea what render target locking is (Google suggests to me that it's a Direct3D feature that Wine's had problems with in the past), and I'm not a graphics programmer (I tend to deal with embedded systems instead). Can we pin this issue down to either a Wine specific bug or a particular ATI driver bug?
Well unless you plan to hack Wine's d3d code, I already told you all you would need to know about RT lock mode - it is controlled by RenderTargetLockMode key and influences this kind of games a lot. So whenever you have problems, it's desirable to test with several RT lock mode settings. Doing so can produce various interesting results, from making the game work, thus giving a usable workaround (it will not mean there is no bug though, but at least game may be usable) to providing some clues into the nature of the problem. The key and its various settings is documented heer: http://wiki.winehq.org/UsefulRegistryKeys. At the moment it's enough to test readtex and readdraw (default = auto = readdraw), because the rest are not fully implemented anyway. Roderick Colenbrander also created another interesting page here: http://wiki.winehq.org/DirectDraw that goes further into technical details.
At the moment it's not very clear where the bug is, although most likely in ATI drivers. Testing the already mentioned RT lock modes may isolate the problem somewhat. Some additional things that may be tested to further narrow it down:
1) testing some opengl samples available on the net that use glDrawPixels (that's basically the call which draws stuff to the screen in Thief menu for example). If it's broken in the driver, then maybe these samples will also not work. Google +glDrawPixels +sample for some free open source samples.
2) checking what happens if you disable PBO. this means you open winesource/dlls/wined3d/directx.c, find the first line with "pixel_buffer_object" and comment it out, then build wine.
http://bugs.winehq.org/show_bug.cgi?id=13954
--- Comment #16 from Michael Abbott michael@araneidae.co.uk 2008-06-29 11:59:47 --- (In reply to comment #15)
Well unless you plan to hack Wine's d3d code
No, no graphic skills, but I'll do tests...
Ah yes.
At the moment it's enough to test readtex and readdraw
RenderTargetLockMode = "readtex" Wow. That's a *lot* better: I get a full screen of menu!
Interesting: the menu animation freezes while I move the mouse. That's a cute "feature".
Let's see how gameplay is... - Well, the frame rate is fairly slow, but it seems playable. - Software mode is a complete write-off: screen is completely black in this mode. Fortunately I don't seem to need it now.
Well, I think that's playable. Let's see how the Thief 2 demo looks... exactly the same, same features: menu animation freezes with moving mouse and rather low frame rate, but looks playable.
I'll try this RenderTargetLockMode="readtex" elsewhere and report back.
I did the "PBO" disable test below, but I'm not sure what needs further investigating now.
- testing some opengl samples available on the net that use glDrawPixels
(that's basically the call which draws stuff to the screen in Thief menu for example). If it's broken in the driver, then maybe these samples will also not work. Google +glDrawPixels +sample for some free open source samples.
Good idea, afraid I'm going to need a canned example for this; I didn't find anything helpful with your search string.
- checking what happens if you disable PBO. this means you open
winesource/dlls/wined3d/directx.c, find the first line with "pixel_buffer_object" and comment it out, then build wine.
I commented out this line: {"GL_ARB_pixel_buffer_object", ARB_PIXEL_BUFFER_OBJECT, 0}, but it didn't make any visible difference to the Thief1 demo test (it's difficult to do more than just run it up and see check that only the top half of the menu display).
Given that we seem to have a workaround, what's the status of this bug now?
http://bugs.winehq.org/show_bug.cgi?id=13954
--- Comment #17 from Alexander Dorofeyev alexd4@inbox.lv 2008-06-29 12:52:35 --- (In reply to comment #16)
Interesting: the menu animation freezes while I move the mouse. That's a cute "feature".
That's known performance issue that is most of all plaguing some 2D games like Red Alert 2 that unfortunately isn't going anywhere any time soon (except maybe by growth in computing power, for example games like Starcraft 1 are already perfectly playable on new machines because they are very overpowered compared to original specs). DirectDraw wiki article covers these problems.
I did the "PBO" disable test below, but I'm not sure what needs further investigating now. but it didn't make any visible difference to the Thief1 demo test (it's difficult to do more than just run it up and see check that only the top half of the menu display).
Well this probably means it isn't pbo-related.
Given that we seem to have a workaround, what's the status of this bug now?
It is more or less clear that it's glDrawPixels path that causes issues.
Good idea, afraid I'm going to need a canned example for this; I didn't find anything helpful with your search string.
Well try this, I didn't download myself but it looks like it should be easy to build via make http://www.cs.mun.ca/~blangdon/opengl/glDrawPixels.html
http://bugs.winehq.org/show_bug.cgi?id=13954
--- Comment #18 from Michael Abbott michael@araneidae.co.uk 2008-06-29 13:12:11 ---
That one runs perfectly, produces exactly the same output as the screenshot on the web page. This is probably a *good* thing ;)
http://bugs.winehq.org/show_bug.cgi?id=13954
--- Comment #19 from Alexander Dorofeyev alexd4@inbox.lv 2008-06-29 14:18:36 --- (In reply to comment #18)
That one runs perfectly, produces exactly the same output as the screenshot on the web page. This is probably a *good* thing ;)
From development point of view this is a bad thing :D. If it failed then it
would be clear where the bug is and there would be nice and simple, helpful testcase for a bugreport to ati. But, alas, no such luck. If you are really sure this worked better before in readdraw(the default) RT lock mode, run a regression test (bisect), as documented in the wiki. Whatever it is, ati bug or not, knowing what particular change started the problem is good. I, unfortunately, am not sure bisect won't run into fatal (for somebody not experienced in Wine development) problems though, as versions around 0.9.59 had a LOT of other breakages, most of all of them fixed by now, but this can be a really major pain in the but when trying to bisect, because some interim versions may simply not run Thief at all. I only have nvidia hardware myself. :(
http://bugs.winehq.org/show_bug.cgi?id=13954
--- Comment #20 from Alexander Dorofeyev alexd4@inbox.lv 2008-06-29 17:17:50 --- Also, if you don't want / can't run bisect or it won't work out, maybe try bugreport to ati. I really have no idea how interested and responsive the vendors of proprietary Linux drivers are (never have to find out with nvidia, fortunatly :D), but you may try to send ATI a report, via whatever means are available. Perhaps they'll show interest. Unfortunately, at this point the details about his bug are not as good as ideally they would be, what is known is that glDrawPixels for some reason is only updating a smaller subsection of drawable.
http://bugs.winehq.org/show_bug.cgi?id=13954
Tobias Jakobi liquid.acid@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |liquid.acid@gmx.net
http://bugs.winehq.org/show_bug.cgi?id=13954
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|CVS/GIT |unspecified
--- Comment #21 from Austin English austinenglish@gmail.com 2009-01-20 02:39:16 --- Removing deprecated CVS/GIT version tag. Please retest in current git. If the bug is still present in today's wine, but was not present in some earlier version of wine, please update version field to earliest known version of wine that had the bug. Thanks!
http://bugs.winehq.org/show_bug.cgi?id=13954
--- Comment #22 from Michael Abbott michael@araneidae.co.uk 2009-03-30 16:34:26 --- Using wine-1.1.18 and ATI Catalyst 9.3 drivers I can report interesting "progress" on this bug -- in fact, I'll create a separate bug report for this.
With no Wine/Direct3D registry keys set, I see perfect rendering of the in game menu (at least, with a virtual desktop) -- but in game rendering is complete garbage. To be a bit more detailed, the image is rendered in multiple repeated flickering horizontal stripes, and is in part upside down.
I've tried the following five combinations for RenderTargetLockMode: default, readtex, texdraw, textex, and disabled. Only disabling RenderTargetLockMode works: in this mode, the in game graphics renders pretty well perfectly -- but the in game menu completely fails to show!
So I can only conclude that whatever RenderTargetLockMode controls is comprehensively broken here.
http://bugs.winehq.org/show_bug.cgi?id=13954
Michael Abbott michael@araneidae.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |ABANDONED
--- Comment #23 from Michael Abbott michael@araneidae.co.uk 2009-06-12 17:08:04 --- This bug appears to be ATI only, and I'm giving up on ATI with Wine. For what it's worth, I'm going to mark this bug as Abandoned.
http://bugs.winehq.org/show_bug.cgi?id=13954
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED CC|michael@araneidae.co.uk |
--- Comment #24 from Dmitry Timoshkov dmitry@codeweavers.com 2009-06-13 07:17:06 --- There is a download link if anyone wants to retest.
-
wine-bugs＠winehq.org