http://bugs.winehq.org/show_bug.cgi?id=13122
Summary: Graphical regression in Team Fortress 2. Product: Wine Version: 0.9.61. Platform: PC-x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: trivial Priority: P5 Component: directx-d3d AssignedTo: wine-bugs@winehq.org ReportedBy: slavikg@gmail.com CC: thunderbird2k@gmx.net
When being killed, the camera zooms to the killer allowing the victim to press F5 to save an image of the killer. In Wine-61 (and rc1) when the camera reaches the killer, the entire screen goes black, although the HUD is still visible.
628e4eece3b9bc724f8873aa3c078f545da887cc is first bad commit commit 628e4eece3b9bc724f8873aa3c078f545da887cc Author: Roderick Colenbrander thunderbird2k@gmx.net Date: Mon Apr 28 21:44:21 2008 +0000
wined3d: Add multisampling support.
:040000 040000 7864ad7f4c0aeaa2235255e8d9065edb796f70d2 0b014ba64337d75aba8298596be87e6c9d3066b3 M dlls :040000 040000 d5eaaeeaa515f68aa03ecf10c3be9f2fbfa6c182 5e8b0f59abb7bec2c8af2c010b673bfb4b1b9801 M include
http://bugs.winehq.org/show_bug.cgi?id=13122
--- Comment #1 from Vyacheslav Goltser slavikg@gmail.com 2008-05-10 21:29:57 --- Created an attachment (id=12906) --> (http://bugs.winehq.org/attachment.cgi?id=12906) screenshot showing the glitch in rc1
The screenshot is what the glitch looks like in RC1 (0.9.61 is the same).
wine-0.9.60 does not experience this.
http://bugs.winehq.org/show_bug.cgi?id=13122
--- Comment #2 from Vyacheslav Goltser slavikg@gmail.com 2008-05-13 00:43:18 --- The app maintainer has said that TF2 works fine on his system, is it possible that me being on a 64bit system could affect this?
http://bugs.winehq.org/show_bug.cgi?id=13122
--- Comment #3 from Roderick Colenbrander thunderbird2k@gmx.net 2008-05-13 01:13:05 --- Most likely not. The videocard + drivers are more important. Which are you using?
http://bugs.winehq.org/show_bug.cgi?id=13122
--- Comment #4 from Vyacheslav Goltser slavikg@gmail.com 2008-05-13 01:34:26 --- nvidia 8800GT 640MB, driver is 169.12 (same as app maintainer).
http://bugs.winehq.org/show_bug.cgi?id=13122
--- Comment #5 from Vyacheslav Goltser slavikg@gmail.com 2008-05-13 01:37:16 --- I do have something interesting to report (just realized it now).
If I go into the menu to select load outs for characters, when I die, the black screen is displayed, but in the upper left corner, an image of the last viewed class which I looked at in the load out appears. (it's as if there is a mixup on which image to display or something of the sort).
http://bugs.winehq.org/show_bug.cgi?id=13122
Paul Johnson baloo@ursine.ca changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |baloo@ursine.ca
http://bugs.winehq.org/show_bug.cgi?id=13122
--- Comment #6 from Paul Johnson baloo@ursine.ca 2008-05-14 02:10:17 --- Created an attachment (id=13043) --> (http://bugs.winehq.org/attachment.cgi?id=13043) Example deathcam shot exhibiting the bug.
The screen goes black, and shows random, oversize text. Sometimes the text changes size, though the text is different every time.
http://bugs.winehq.org/show_bug.cgi?id=13122
--- Comment #7 from Paul Johnson baloo@ursine.ca 2008-05-14 02:10:28 --- Created an attachment (id=13044) --> (http://bugs.winehq.org/attachment.cgi?id=13044) Example deathcam shot exhibiting the bug.
The screen goes black, and shows random, oversize text. Sometimes the text changes size, though the text is different every time.
http://bugs.winehq.org/show_bug.cgi?id=13122
--- Comment #8 from Paul Johnson baloo@ursine.ca 2008-05-14 02:10:29 --- Created an attachment (id=13045) --> (http://bugs.winehq.org/attachment.cgi?id=13045) Example deathcam shot exhibiting the bug.
The screen goes black, and shows random, oversize text. Sometimes the text changes size, though the text is different every time.
http://bugs.winehq.org/show_bug.cgi?id=13122
--- Comment #9 from Paul Johnson baloo@ursine.ca 2008-05-14 02:18:55 --- I'm getting it, too, though in a slightly different form on the deathcam shots. This bug presents a severe disadvantage to wine users in Team Fortress 2 as it prevents people from getting a good look at how they were killed. I have attached a few screenshots showing example output of this bug.
I noticed this in 0.9.61 and RC1, prior to that, I did not play TF2.
Currently using RC1, using an nVidia FX5500 256MB, driver is legacy 96.43.05.
http://bugs.winehq.org/show_bug.cgi?id=13122
Paul Johnson baloo@ursine.ca changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #10 from Paul Johnson baloo@ursine.ca 2008-05-19 22:23:23 --- *** This bug has been confirmed by popular vote. ***
http://bugs.winehq.org/show_bug.cgi?id=13122
--- Comment #11 from Roderick Colenbrander thunderbird2k@gmx.net 2008-05-20 11:02:56 --- Check if it works in the latest GIT version as I have and others have added some fixes to it which could affect this bug.
http://bugs.winehq.org/show_bug.cgi?id=13122
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rmuncrief@comcast.net
--- Comment #12 from Vitaliy Margolen vitaliy@kievinfo.com 2008-05-21 08:34:21 --- *** Bug 13334 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=13122
--- Comment #13 from Robert M. Muncrief rmuncrief@comcast.net 2008-05-21 08:49:49 --- (In reply to comment #12)
*** Bug 13334 has been marked as a duplicate of this bug. ***
I just filed bug 13334 but it was immediately marked as a duplicate of this one. Bisect did identify the same commit, but I wanted to be sure the developer was aware that my bug was about the full Steam Half-Life 2 and HL2 Episode One games, and the Demo call of Duty 2, and the bug presents itself a little differently.
http://bugs.winehq.org/show_bug.cgi?id=13122
Stefan Dösinger stefandoesinger@gmx.at changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefandoesinger@gmx.at
--- Comment #14 from Stefan Dösinger stefandoesinger@gmx.at 2008-05-21 09:48:35 --- It's possible that the framebuffer readback fails with multisampled framebuffers. Did you enable multisampling(antialiasing) in the game's settings? Can you try to disable it? Are you using fbos, or the default offscreen rendering method? I guess we're not enabling multisampling for fbos, so glBlitFramebuffer might fail.
http://bugs.winehq.org/show_bug.cgi?id=13122
--- Comment #15 from Robert M. Muncrief rmuncrief@comcast.net 2008-05-21 10:05:18 --- (In reply to comment #14)
It's possible that the framebuffer readback fails with multisampled framebuffers. Did you enable multisampling(antialiasing) in the game's settings? Can you try to disable it? Are you using fbos, or the default offscreen rendering method? I guess we're not enabling multisampling for fbos, so glBlitFramebuffer might fail.
Yes, the default settings for the games use antialiasing, and I'm using fbo's. They have to be used because not using them causes games run at a crawl (2 to 13 FPS instead of 20 to 180 FPS for Half Life games). I should have specified my video settings, but I've always thought opengl with fbo was the default for all games. That what I've always used, and until this regression error it always worked great.
I've been messing around with a lot of configurations and trying to get all my regular suite of apps and games to work so I'm too tired to do another recompile now. But I'll pull the latest git tomorrow and see if turning off all anti aliasing works around the problem, but I would still think its something that needs to be fixed because it can dramatically improve graphics quality, and like I said always worked before this regression error.
http://bugs.winehq.org/show_bug.cgi?id=13122
--- Comment #16 from Paul Johnson baloo@ursine.ca 2008-05-21 14:03:48 --- I've had antialiasing turned off the entire time (since I know enabling them destroys framerates like nothing else on an FX5500). I've tried both FBO (due to another game) and the default (whatever that is) with no discernable change whatsoever. What's a GIT version, and what would it's package name be in Debian Sid?
http://bugs.winehq.org/show_bug.cgi?id=13122
--- Comment #17 from Austin English austinenglish@gmail.com 2008-05-21 14:33:00 --- (In reply to comment #16)
I've had antialiasing turned off the entire time (since I know enabling them destroys framerates like nothing else on an FX5500). I've tried both FBO (due to another game) and the default (whatever that is) with no discernable change whatsoever. What's a GIT version, and what would it's package name be in Debian Sid?
You'll have to compile it youself from git (sort of like CVS). See: http://wiki.winehq.org/GitWine
http://bugs.winehq.org/show_bug.cgi?id=13122
--- Comment #18 from Robert M. Muncrief rmuncrief@comcast.net 2008-05-21 22:46:26 --- OK, I did a reinstall of git as of about 3:00PM today and the problem with blank videos in the games I reported is indeed the lack of anti-aliasing support when using fbo.
If I turned anti-aliasing completely off in Half-Life 2, Episode One, and Call of Duty 2 all the previously blank video portions played fine.
I was then curious to see the actual effect of anti-aliasing on the game suite I'm running so I booted up my standby XP installation and ran them. The lack of anti-aliasing in Wine was then quite apparent. Without anti-aliasing games run under Wine have a pronounced "shimmering" effect when moving, and when stationary the edges of objects are noticeably jagged.
I hope that anti-aliasing can be implemented when using fbo, because without fbo games simply run to slow to be usable.
In the least case however, something should be done so that if a game requests the use of anti-aliasing that it be ignored. I noticed that some games, like Far Cry 2, seem to detect the lack of anti-aliasing support and don't try to use it. Most games seem to think there is some level of anti-aliasing support though, and this can certainly cause problems for users that expect a game to run with automatically detected settings.
http://bugs.winehq.org/show_bug.cgi?id=13122
--- Comment #19 from Vyacheslav Goltser slavikg@gmail.com 2008-05-22 01:23:44 --- just updated my git tree (git fetch; git rebase origin)
wine-1.0-rc1-182-g9f76085
bug still present. tried turning MSAA off, but that did not help.
http://bugs.winehq.org/show_bug.cgi?id=13122
--- Comment #20 from Roderick Colenbrander thunderbird2k@gmx.net 2008-05-22 01:27:35 --- It doesn't proof it has to do with FBOs yet. You should set the OffscreenRenderingMethod to backbuffer and if it works in that mode with antialiasing then it is a FBO problem for sure.
http://bugs.winehq.org/show_bug.cgi?id=13122
--- Comment #21 from H. Verbeet hverbeet@gmail.com 2008-05-22 04:03:06 --- As a random guess, I'd say stretch_rect_fbo() doesn't handle blitting to/from multisampled buffers.
http://bugs.winehq.org/show_bug.cgi?id=13122
--- Comment #22 from Robert M. Muncrief rmuncrief@comcast.net 2008-05-22 05:08:20 --- (In reply to comment #20)
It doesn't proof it has to do with FBOs yet. You should set the OffscreenRenderingMethod to backbuffer and if it works in that mode with antialiasing then it is a FBO problem for sure.
I just spent awhile running the Half Life and Call of Duty 2 games and verified that anti-aliasing works with OffscreenRenderingMode set to pbuffer or backbuffer. I just let wine pick whatever RenderTargetLockMode it wanted.
OpenGL games actually only seem to suffer around a 20% to 40% drop in FPS with backbuffer and anti-aliasing set to 2x, so Half Life and COD are playable, and the quality of the AA looks quite good. However, with AA any higher the FPS go down very quickly. DirectX games were not playable in backbuffer mode at all though. I literally almost ate a whole bag of microwave popcorn waiting for Need for Speed Pro Street to get to the first selection screen.
And neither OpenGL or DirectX games run very well with pbuffer, although they do work and you can see the beneficial effects of AA.
So there definitely appears to be a problem with AA and FOB, at least with the games I'm using.
I just want to say again though, the quality of the AA was very good, just as good as under Windows to these untrained eyes. If it worked with FOB it would be awesome!
http://bugs.winehq.org/show_bug.cgi?id=13122
--- Comment #23 from H. Verbeet hverbeet@gmail.com 2008-05-22 05:57:32 --- Actually... the issue could also be doing eg. ReadPixels or CopyTexImage on a multisampled FBO. In principle these should always be redundant when FBOs are used, but I'm not completely sure they never happen. Are there any GL errors in your console output?
http://bugs.winehq.org/show_bug.cgi?id=13122
--- Comment #24 from Stefan Dösinger stefandoesinger@gmx.at 2008-05-22 06:01:14 --- Commenting out GL_EXT_framebuffer_blit from the extension table in direct.c could show if it's a problem with fb_blit or not.
I guess the glCopyTexImage2D with offscreenrenderingmode != fbo causes the slow performance with multisampling.
http://bugs.winehq.org/show_bug.cgi?id=13122
--- Comment #25 from Robert M. Muncrief rmuncrief@comcast.net 2008-05-22 19:41:32 --- Created an attachment (id=13267) --> (http://bugs.winehq.org/attachment.cgi?id=13267) Half Life 2/Wine Bad Video Test
OK, I ran a semi-formal test with Half-Life 2 using both "fbo" and "backbuffer" and attached the test setup and console output.
http://bugs.winehq.org/show_bug.cgi?id=13122
--- Comment #26 from Robert M. Muncrief rmuncrief@comcast.net 2008-05-22 19:52:27 --- (In reply to comment #24)
Commenting out GL_EXT_framebuffer_blit from the extension table in direct.c could show if it's a problem with fb_blit or not.
I guess the glCopyTexImage2D with offscreenrenderingmode != fbo causes the slow performance with multisampling.
I'm not familiar with Wine architecture, but I'd be happy to run the test if you give me a little more instruction. After commenting out GL_EXT_framebuffer_blit what should I expect to see/not see? What tests would you like to be run?
I'm also not familiar with glCopyTexImage2D, but if there's a problem with data transfer or manipulation and there's at least some semi-defined I/O and architectural documentation I could try fixing it. I have a few decades of experience as a digital hardware/firmware/software designer, but as I said I know nothing about the internals of Wine.
http://bugs.winehq.org/show_bug.cgi?id=13122
--- Comment #27 from H. Verbeet hverbeet@gmail.com 2008-05-23 06:26:43 ---
phalynx@entropod:~$ env WINEPREFIX="/home/phalynx/.wine" WINEDEBUG="fixme-all" wine "C:\Program Files\Steam\Steam.exe" -applaunch 220 -heapsize 1024000
You'll have to remove the WINEDEBUG="fixme-all" part, or GL errors won't show. If EXT_framebuffer_blit is the problem, commenting out the extension should fix the blank video.
http://bugs.winehq.org/show_bug.cgi?id=13122
--- Comment #28 from Robert M. Muncrief rmuncrief@comcast.net 2008-05-23 22:02:59 --- Created an attachment (id=13291) --> (http://bugs.winehq.org/attachment.cgi?id=13291) Half-Life 2 Blank Video GL_EXT_framebuffer_blit test
Nice call gentlemen. GL_EXT_framebuffer_blit is indeed the problem. I've attached a test report with the details and console output. Please let me know if you need anything else.
http://bugs.winehq.org/show_bug.cgi?id=13122
Robert M. Muncrief rmuncrief@comcast.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #13291|0 |1 is obsolete| |
--- Comment #29 from Robert M. Muncrief rmuncrief@comcast.net 2008-05-23 22:08:13 --- Created an attachment (id=13292) --> (http://bugs.winehq.org/attachment.cgi?id=13292) Half-Life 2 Blank Video GL_EXT_framebuffer_blit test
Aaarg, sorry people. I keep forgetting to put hard CR/LF's in my reports. Here's the same report with CR/LF's.
http://bugs.winehq.org/show_bug.cgi?id=13122
Phil Costin philcostin@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |philcostin@hotmail.com
--- Comment #30 from Phil Costin philcostin@hotmail.com 2008-05-24 13:59:09 --- Garry's Mod is not visible after launching it and on launching Counter-Strike: Source, the background is visible but not the main menu
Used bisect to get to this.
http://bugs.winehq.org/show_bug.cgi?id=13122
--- Comment #31 from Stefan Dösinger stefandoesinger@gmx.at 2008-05-24 14:33:03 --- philcostin: Try to disable HDR - that may get you around the absolutely not visible problem.
http://bugs.winehq.org/show_bug.cgi?id=13122
--- Comment #32 from Vyacheslav Goltser slavikg@gmail.com 2008-06-20 21:40:24 --- Using Wine 1.0 (compiled it myself) in Ubuntu Hardy 8.04 (amd64) I am not longer experiencing this regression (everything works). As far as I am concerned, this bug can be closed.
http://bugs.winehq.org/show_bug.cgi?id=13122
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #33 from Dmitry Timoshkov dmitry@codeweavers.com 2008-06-20 22:46:23 --- Reported fixed.
http://bugs.winehq.org/show_bug.cgi?id=13122
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #34 from Alexandre Julliard julliard@winehq.org 2008-06-27 10:15:33 --- Closing bugs fixed in 1.1.0.
http://bugs.winehq.org/show_bug.cgi?id=13122
--- Comment #35 from Paul Johnson baloo@ursine.ca 2008-07-20 18:11:27 --- I still see this in 1.1.1, please reopen.
http://bugs.winehq.org/show_bug.cgi?id=13122
--- Comment #36 from Stefan Dösinger stefandoesinger@gmx.at 2008-07-20 19:01:20 --- Paul Johnson, there's a different problem with up to dx9 radeon cards(X1x00 and earlier), as well as GeForce FX and earlier cards that should be fixed in current git