[Bug 13954] Only top half of screen visible

wine-bugs at winehq.org wine-bugs at winehq.org
Sun Jun 29 09:46:28 CDT 2008


http://bugs.winehq.org/show_bug.cgi?id=13954


Michael Abbott <michael at araneidae.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |michael at araneidae.co.uk




--- Comment #13 from Alexander Dorofeyev <alexd4 at 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 at 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).


-- 
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.



More information about the wine-bugs mailing list