http://bugs.winehq.org/show_bug.cgi?id=11970
Summary: graphic bug with 0.9.57 in serius sam - the second encounter Product: Wine Version: 0.9.57. Platform: Other OS/Version: other Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: jb.faq@gmx.de
Created an attachment (id=11299) --> (http://bugs.winehq.org/attachment.cgi?id=11299) graphic bug: a look throug hills
Hi, with the new version 0.9.57 of wine the graphic rendering in Serious Sam - The Second encounter breaks. You can look through hills, walls or the earth. I'll upload a screeshot in some few minutes, because it describe the error in the best way.
Greetings Jan
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #1 from Jan Buecken jb.faq@gmx.de 2008-03-10 09:21:59 --- Created an attachment (id=11300) --> (http://bugs.winehq.org/attachment.cgi?id=11300) graphic bug: look in the earth
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #2 from Jan Buecken jb.faq@gmx.de 2008-03-10 09:22:55 --- Created an attachment (id=11301) --> (http://bugs.winehq.org/attachment.cgi?id=11301) graphic bug: black ufo
http://bugs.winehq.org/show_bug.cgi?id=11970
Tobias Jakobi liquid.acid@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |liquid.acid@gmx.net
--- Comment #3 from Tobias Jakobi liquid.acid@gmx.net 2008-03-10 09:55:40 --- Confirming this. It's a regression (keywords should be added).
Bug doesn't appear with wine-0.9.56, but with wine-0.9.57. Going to try a git bisect later this week.
Any thoughts about the faulty component?
http://bugs.winehq.org/show_bug.cgi?id=11970
Jan Buecken jb.faq@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression Summary|graphic bug with 0.9.57 in |serious sam - the second |serius sam - the second |encounter 1.07: graphic bug |encounter |(zorder)
http://bugs.winehq.org/show_bug.cgi?id=11970
Jan Buecken jb.faq@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|serious sam - the second |Serious Sam TSE 1.07: |encounter 1.07: graphic bug |graphic bug (z-order) |(zorder) |
http://bugs.winehq.org/show_bug.cgi?id=11970
Jan Buecken jb.faq@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #4 from Jan Buecken jb.faq@gmx.de 2008-03-10 10:04:30 --- *** This bug has been confirmed by popular vote. ***
http://bugs.winehq.org/show_bug.cgi?id=11970
Leslie Viljoen leslieviljoen@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |leslieviljoen@gmail.com
--- Comment #5 from Leslie Viljoen leslieviljoen@gmail.com 2008-03-13 04:05:10 --- I confirm that this is happening with Sacrifice (both standard and patched) too, and was not happening with 0.9.56. I am running on Ubuntu 7.10.
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #6 from Timo-Heikki Mäkelä imaxfun@gmail.com 2008-03-13 11:33:15 --- (In reply to comment #3)
Any thoughts about the faulty component?
You'll find it out through the bisection. I'd place my bets on it being 'directx-d3d, but don't change it from 'unknown' before you know it for sure.
Just in case you need instructions for the bisection: http://wiki.winehq.org/RegressionTesting
Btw, this is likely a bug on PC (32-bit) and Linux, right? Those could be added to the summary above, if that's the case.
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #7 from Tobias Jakobi liquid.acid@gmx.net 2008-03-13 12:03:18 --- Jan can confirm this on a 32-bit architecture, I tested this on a 64-bit system (with 32-bit compat of course).
http://bugs.winehq.org/show_bug.cgi?id=11970
Jan Buecken jb.faq@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- OS/Version|other |Linux Platform|Other |PC
http://bugs.winehq.org/show_bug.cgi?id=11970
Jan Buecken jb.faq@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|enhancement |major
http://bugs.winehq.org/show_bug.cgi?id=11970
James Hawkins truiken@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|major |normal
--- Comment #8 from James Hawkins truiken@gmail.com 2008-03-13 12:51:57 --- Please read the severity definitions. This is not major.
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #9 from Tobias Jakobi liquid.acid@gmx.net 2008-03-13 14:03:28 --- As a previous counter-strike gamer I consider this "wall-hack" a major loss of functionality :-D
(to all the cheaters out there: use wine, it's not a bug, it's a feature!)
Just kidding, I still have to bisect the source. Gonna try it this evening.
http://bugs.winehq.org/show_bug.cgi?id=11970
Tobias Jakobi liquid.acid@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |thunderbird2k@gmx.net
--- Comment #10 from Tobias Jakobi liquid.acid@gmx.net 2008-03-13 19:31:10 --- Ok, bisect is done. The faulty patch appears to be: [8293a9ead0ddbc40be62815f0f0823356665b3dc] wgl: Remove the pixel format limitation.
http://source.winehq.org/git/wine.git/?a=commit;h=8293a9ead0ddbc40be62815f0f...
Adding Roderick to the CC.
@Jan: You can now change the component type.
n8 everyone ;-)
git bisect log: git-bisect start # good: [14991a42d1d28ae114f8f06f5e3ca209aefd87a7] Release 0.9.56. git-bisect good 14991a42d1d28ae114f8f06f5e3ca209aefd87a7 # bad: [a32e36aee5684abca33001eea3a0768ab603c373] Release 0.9.57. git-bisect bad a32e36aee5684abca33001eea3a0768ab603c373 # bad: [e6cbde105f81990bb96c5b243e78ba77582f28ba] qmgr: Implement IBackgroundCopyFile_GetProgress. git-bisect bad e6cbde105f81990bb96c5b243e78ba77582f28ba # bad: [62694157936baf64d20ab10e2c464bd1b1d6d34b] wined3d: Add GL_APPLE_float_pixels. git-bisect bad 62694157936baf64d20ab10e2c464bd1b1d6d34b # bad: [45322bb4485664d322c112fc8008043d78ae3727] explorer: Clean up after CreateProcess in WinMain. git-bisect bad 45322bb4485664d322c112fc8008043d78ae3727 # bad: [8b540d2670afe2c7c75c51b0cb6ae97169444323] msi: Fix the INSTALLPROPERTY_LASTUSEDTYPE case. git-bisect bad 8b540d2670afe2c7c75c51b0cb6ae97169444323 # good: [68467cf344e51f0ee0773d7e876916a4f8998e68] wined3d: Request alpha in backbuffer mode, to work correctly with multiple opengl pixel formats. git-bisect good 68467cf344e51f0ee0773d7e876916a4f8998e68 # bad: [a7ba7647adf6ac2f25a8fa9c097bfd20537fd392] mshtml: Added IHTMLBodyElement::put_link implementation. git-bisect bad a7ba7647adf6ac2f25a8fa9c097bfd20537fd392 # bad: [5374d623ce6ee7ab6913a3453ef64c3ac55320d8] wgl: Add aux buffers support to DescribePixelFormat. git-bisect bad 5374d623ce6ee7ab6913a3453ef64c3ac55320d8 # bad: [220163ee9d698543fe34257969a88e5976d378de] wgl: Remove unneeded opengl initialisation code at wine startup. git-bisect bad 220163ee9d698543fe34257969a88e5976d378de
http://bugs.winehq.org/show_bug.cgi?id=11970
Roderick Colenbrander thunderbird2k@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |opengl
--- Comment #11 from Roderick Colenbrander thunderbird2k@gmx.net 2008-03-14 04:13:24 --- I can't say this way what the problem is. Is the game using OpenGL? If so run using WINEDEBUG=+wgl and attach the log.
In short I don't understand why this patch would cause issues. For years wine's opengl has been limited to the use of 1 pixel format. As of the patch this limitation was lifted (because Alexandre fixed the parts which caused the limitation). The patch adds dozens of more pixel formats which should make games a lot happier.
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #12 from Tobias Jakobi liquid.acid@gmx.net 2008-03-14 04:35:46 --- (In reply to comment #11)
I can't say this way what the problem is. Is the game using OpenGL? If so run using WINEDEBUG=+wgl and attach the log.
Yep, the game engine was using OpenGL. It's also possible to switch it into D3D mode, but I didn't think about that while testing. I think I give D3D mode a try, maybe the problem does not appear there.
I can create a debug log in a few hours. Going to ask Jan if he's able to do it (faster this way). Also Jan wanted to do his own bisect, so he could verify the faulty commit I found (maybe I did a mistake while bisecting? But I'm pretty sure I did NOT...)
In short I don't understand why this patch would cause issues. For years wine's opengl has been limited to the use of 1 pixel format. As of the patch this limitation was lifted (because Alexandre fixed the parts which caused the limitation). The patch adds dozens of more pixel formats which should make games a lot happier.
Frankly I was expecting the wgl aux buffers commit to pop up, or something related to front/back buffer stuff.
Gonna report back as soon as the log is done. I also gonna check if the visual error appears with the "First Encounter".
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #13 from Tobias Jakobi liquid.acid@gmx.net 2008-03-14 04:39:55 --- Almost forgot: http://www.fileplanet.com/82639/80000/fileinfo/Serious-Sam:-The-Second-Encou...
A link to the Serious Sam TSE demo. However I din't test if the problem appears with the demo. Just in case someone wants to make a test and doesn't own the game. I'm also checking this, but not now.
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #14 from Tobias Jakobi liquid.acid@gmx.net 2008-03-14 06:52:38 --- News: I'm currently testing this on the system in my office (on campus). The system here is (unfortunately) only equiped with a integrated graphics chipset, a i945.
lspci output: 00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02)
At home I'm using a Geforce 5900 card.
The demo however, when run on the i945 shows the same graphic errors. @Roderick: I'm doing a wgl debug log on this machine with wine-0.9.57 but I suggest you try the demo yourself. In case someone does not have a FilePlanet login you can also get the package at: http://www.4players.de/4players.php/download_info/PC-CDROM/Download/3130.htm... http://files.seriouszone.com/download.php?fileid=338
I didn't change the config in the demo, everything left on standard values and the bugs already appear in the intro demo.
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #15 from Tobias Jakobi liquid.acid@gmx.net 2008-03-14 07:01:31 --- Created an attachment (id=11374) --> (http://bugs.winehq.org/attachment.cgi?id=11374) SeriousSam log file that the game engine itself creates
I'm also attaching this log because it could contain valuable information
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #16 from Tobias Jakobi liquid.acid@gmx.net 2008-03-14 07:02:14 --- Created an attachment (id=11375) --> (http://bugs.winehq.org/attachment.cgi?id=11375) SeriousSam WINEDEBUG=+wgl log
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #17 from Roderick Colenbrander thunderbird2k@gmx.net 2008-03-14 08:28:13 --- Does the problem happen on videocards from different vendors?
At least due to the pixel format change there are now dozens of pixel formats to choose from. If the issue appears only on a certain driver then it is most likely a driver bug (e.g. the driver not liking the specific format). It could also be a bug in our opengl32 code where we might not return the correct info for a certain pixel format. Even then the issue might only appear on certain drivers because due to the way each driver orders the pixel format list, the game might have received a different format.
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #18 from Jan Buecken jb.faq@gmx.de 2008-03-14 09:11:23 --- Hi, I confirm the bug again with the serious sam tse demo (version 1.05) and I tested it again with my installed 1.07 to make sure that the bug is present.
I use a nvidia card: lspci:
01:00.0 VGA compatible controller: nVidia Corporation NV17 [GeForce4 440 Go 64M] (rev a3)
with the "newest" driver for this card. "newest" means that I have to use the newest legacy driver:
nvidia-drivers 96.43.05
It seems to me that this is not driver or videocard vendor specific because this uppaers on a intel and a newer nvida card too...
Hint: With direct3d this is not really a z-order problem because I get a black screen only... ;-)
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #19 from Tobias Jakobi liquid.acid@gmx.net 2008-03-14 09:22:48 --- (In reply to comment #17)
Does the problem happen on videocards from different vendors?
Sure, like I said I can confirm it with the Intel i945 graphics chipset on the campus computer system (I don't know the driver version though). Then I can confirm it on a NV35 series nvidia card (the Geforce 5900 I mentioned before). I find out the driver version of the NV35 this evening. But I really doubt it's a hardware/driver problem (as it's not only happening with nv hardware).
At least due to the pixel format change there are now dozens of pixel formats to choose from. If the issue appears only on a certain driver then it is most likely a driver bug (e.g. the driver not liking the specific format). It could also be a bug in our opengl32 code where we might not return the correct info for a certain pixel format. Even then the issue might only appear on certain drivers because due to the way each driver orders the pixel format list, the game might have received a different format.
I have currently hard-masked a recent nv driver for my NV35 (169.xx ??? series). I could however remove the mask and test SS with this driver. Anything more I can do?
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #20 from Roderick Colenbrander thunderbird2k@gmx.net 2008-03-14 13:55:50 --- Can you run it using +wgl,+opengl? There is some old debug code inside the WGL code left which only responds to +opengl .. the code in question reveals which exact pixel format serious sam likes to have.
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #21 from Tobias Jakobi liquid.acid@gmx.net 2008-03-14 14:01:08 --- (From update of attachment 11374) Run from the demo version on an Intel i945 chipset
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #22 from Tobias Jakobi liquid.acid@gmx.net 2008-03-14 14:01:30 --- (From update of attachment 11375) Run of the demo version on a Intel i945 chipset
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #23 from Roderick Colenbrander thunderbird2k@gmx.net 2008-03-14 14:03:53 --- The glxinfo output of the system you generated the +wgl,+opengl log on would be useful too.
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #24 from Tobias Jakobi liquid.acid@gmx.net 2008-03-14 14:14:14 --- Adding system info about my desktop at home:
uname -a: Linux voodoomaster 2.6.23-gentoo-r9 #2 Sun Mar 9 12:36:03 CET 2008 x86_64 AMD Athlon(tm) 64 Processor 3500+ AuthenticAMD GNU/Linux
x11-drivers/nvidia-drivers-100.14.19
lspci: 01:00.0 VGA compatible controller: nVidia Corporation NV35 [GeForce FX 5900] (rev a1)
Logs are coming in a few minutes. I'm doing 3 logs (SS TFE, SS TSE and SS TSE demo)
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #25 from Tobias Jakobi liquid.acid@gmx.net 2008-03-14 14:15:28 --- Created an attachment (id=11385) --> (http://bugs.winehq.org/attachment.cgi?id=11385) glxinfo from the desktop systme (NV35 gpu)
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #26 from Roderick Colenbrander thunderbird2k@gmx.net 2008-03-14 14:27:22 --- Try to run it using: WINEDEBUG=+wgl,+d3d and a time using +wgl,+opengl as it seems the game also uses d3d and I need to know upto which point.
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #27 from Tobias Jakobi liquid.acid@gmx.net 2008-03-14 14:51:33 --- These logs get quite huge. I'm currently bzip2ing the first set (containing the opengl run).
I don't know if the game will run in d3d mode. I never really tested that. Going to give it a try after the first batch of logs is uploaded.
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #28 from Tobias Jakobi liquid.acid@gmx.net 2008-03-14 14:54:42 --- Oh sry, I misunderstood your statement about d3d. Going to try that.
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #29 from Tobias Jakobi liquid.acid@gmx.net 2008-03-14 15:02:05 --- Created an attachment (id=11386) --> (http://bugs.winehq.org/attachment.cgi?id=11386) WINEDEBUG=+wgl,+opengl log from Serious Sam TFE
The problem also appears with "The First Encounter", there is not much difference. Run was made on NV35 hardware.
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #30 from Tobias Jakobi liquid.acid@gmx.net 2008-03-14 15:14:45 --- Created an attachment (id=11387) --> (http://bugs.winehq.org/attachment.cgi?id=11387) WINEDEBUG=+wgl,+opengl log from Serious Sam TSE Demo
Run on NV35 hardware
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #31 from Tobias Jakobi liquid.acid@gmx.net 2008-03-14 15:21:55 --- Created an attachment (id=11388) --> (http://bugs.winehq.org/attachment.cgi?id=11388) WINEDEBUG=+wgl,+opengl log from Serious Sam TSE (Full)
Run on NV35
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #32 from Tobias Jakobi liquid.acid@gmx.net 2008-03-14 15:29:00 --- Created an attachment (id=11389) --> (http://bugs.winehq.org/attachment.cgi?id=11389) WINEDEBUG=+wgl,+d3d log from Serious Sam TFE
Run on NV35
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #33 from Tobias Jakobi liquid.acid@gmx.net 2008-03-14 15:29:33 --- Created an attachment (id=11390) --> (http://bugs.winehq.org/attachment.cgi?id=11390) WINEDEBUG=+wgl,+d3d log from Serious Sam TSE Demo
Run on NV35
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #34 from Tobias Jakobi liquid.acid@gmx.net 2008-03-14 15:30:07 --- Created an attachment (id=11391) --> (http://bugs.winehq.org/attachment.cgi?id=11391) WINEDEBUG=+wgl,+d3d log from Serious Sam TSE (Full)
Run on NV35
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #35 from Roderick Colenbrander thunderbird2k@gmx.net 2008-03-14 16:15:18 --- As I suspected the initial part of the log is wined3d. Starting from the CoGetClassObject lines it is opengl32 itself. The game seems to request a standard double buffered r/g/b/a pixel format and it nicely gets that. It could be that windows is less strict and returns a format with depth/stencil which is what the game seems to like better.
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #36 from Jan Buecken jb.faq@gmx.de 2008-03-14 18:07:47 --- Created an attachment (id=11392) --> (http://bugs.winehq.org/attachment.cgi?id=11392) bisect verified: log and output of the affected patch
Hello out there, I see that many things happend, hence I don't know if it is important yet, but I verfied the bisect / regression test that Tobias made. The log and the last output with the affected patch of the bisect you can find in the attachment. It looks for me that I get the same result and the logs are identical.
Good night, Jan
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #37 from Tobias Jakobi liquid.acid@gmx.net 2008-03-14 18:17:38 --- The MIME type of your attachment is wrong.
Und Jan, du hast Lag! :-P
http://bugs.winehq.org/show_bug.cgi?id=11970
Jan Buecken jb.faq@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #11392|application/octet-stream |text/plain mime type| |
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #38 from Tobias Jakobi liquid.acid@gmx.net 2008-03-15 12:04:15 --- (In reply to comment #5)
I confirm that this is happening with Sacrifice (both standard and patched) too, and was not happening with 0.9.56. I am running on Ubuntu 7.10.
I found a demo for Sacrifice here: http://www.4players.de/rendersite.php?LAYOUT=download_info&DOWNLOADID=71...
Can you confirm that it happens with the demo too? I think Roderick would be interested in some logs from another game, right?
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #39 from Roderick Colenbrander thunderbird2k@gmx.net 2008-03-15 12:19:25 --- Sacrifice doesn't use OpenGL (well, using WineD3D), so that would be a WineD3D bug.
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #40 from Jan Buecken jb.faq@gmx.de 2008-03-15 17:00:50 --- (In reply to comment #38)
I found a demo for Sacrifice here: http://www.4players.de/rendersite.php?LAYOUT=download_info&DOWNLOADID=71...
This link doesn't work for me if I try to download it (error message that the file doesn't exists). Used this link http://downloads.gamezone.com/demosfiles/t1699.htm
Can you confirm that it happens with the demo too? I think Roderick would be interested in some logs from another game, right?
I'm sorry, I can select DirectDraw HAL with Wine D3D7 HAL/RGB/T&L HAL only. With this I get many rendering problems (black figures, a black square behind the mouse, white grassland, etc..). I think I open a own bug for this. But I cannot test the bug since this problem holds.
Greetings Jan
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #41 from Leslie Viljoen leslieviljoen@gmail.com 2008-03-16 14:20:15 ---
I'm sorry, I can select DirectDraw HAL with Wine D3D7 HAL/RGB/T&L HAL only. With this I get many rendering problems (black figures, a black square behind the mouse, white grassland, etc..). I think I open a own bug for this. But I cannot test the bug since this problem holds.
The transparency problem is known: http://bugs.winehq.org/show_bug.cgi?id=201 Apparently some people see it, some don't and there has been a patch but obviously it didn't fix the problem completely.
The z-order problem is much worse IMO. I will download and try the demo.
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #42 from Tobias Jakobi liquid.acid@gmx.net 2008-03-22 19:18:08 --- Reconfirming this with wine-0.9.58 and a GIT snapshot I just checked out.
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #43 from Roderick Colenbrander thunderbird2k@gmx.net 2008-03-30 15:41:53 --- I have no idea when this bug will be fixed as I have no idea how to fix it without breaking most other opengl programs. It looks like a bug in the game. It only asks for the following capabilities: trace:wgl:dump_PIXELFORMATDESCRIPTOR - size / version : 40 / 1 trace:wgl:dump_PIXELFORMATDESCRIPTOR - dwFlags : PFD_DOUBLEBUFFER PFD_DRAW_TO_WINDOW PFD_SUPPORT_OPENGL trace:wgl:dump_PIXELFORMATDESCRIPTOR - iPixelType : PFD_TYPE_RGBA trace:wgl:dump_PIXELFORMATDESCRIPTOR - Color : 32 trace:wgl:dump_PIXELFORMATDESCRIPTOR - Red : 0 trace:wgl:dump_PIXELFORMATDESCRIPTOR - Green : 0 trace:wgl:dump_PIXELFORMATDESCRIPTOR - Blue : 0 trace:wgl:dump_PIXELFORMATDESCRIPTOR - Alpha : 0 trace:wgl:dump_PIXELFORMATDESCRIPTOR - Accum : 0 trace:wgl:dump_PIXELFORMATDESCRIPTOR - Depth : 0 trace:wgl:dump_PIXELFORMATDESCRIPTOR - Stencil : 0 trace:wgl:dump_PIXELFORMATDESCRIPTOR - Aux : 0 trace:wgl:dump_PIXELFORMATDESCRIPTOR - iLayerType : PFD_MAIN_PLANE
In the game it really seems to need depth/stencil buffers. Sure windows ChoosePixelFormat doesn't have to return a format which matches exactly the request. Perhaps some windows drivers guess that you want depth/stencil if you aren't asking for it or so.
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #44 from Tobias Jakobi liquid.acid@gmx.net 2008-03-30 17:01:48 --- Why was it working with wine-0.9.56 then?
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #45 from Roderick Colenbrander thunderbird2k@gmx.net 2008-03-31 02:14:01 --- Before we were limited to a single pixel format in Wine. We requested alpha, stencil, depth and other flags to make most apps sort of happy. This was finally fixed in .57.
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #46 from Tobias Jakobi liquid.acid@gmx.net 2008-03-31 05:26:17 --- I can't believe this is a game bug. The bug must have gone unnoticed through all versions of the game. It's present in Serious Sam The First Encounter, all versions and also in The Second Encounter. As the game was played by a rather large community with different graphic adapters I think the probability of nobody encountering such a bug is very low.
But you're right. Even the ingame log gives:
Pixel Format Description: Number: 1 (TYPE_RGBA) Flags: DRAW_TO_WINDOW SUPPORT_OPENGL DOUBLEBUFFER Color bits: 32 (8:8:8:8) Depth bits: 0 (0 for stencil)
Gonna ask Jan if he can test this in a native Windows environment. Maybe running the game native makes it behave differently.
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #47 from Roderick Colenbrander thunderbird2k@gmx.net 2008-03-31 07:18:11 --- We have had the opengl pixel format limitation in wine for years. I did some basic testing on windows and it appears that on windows (depending on I guess the driver) you can indeed receive a depth + stencil format for this 'bad' request. It appears that ChoosePixelFormat returns the first format which matches the set requirements. Because the first format which matches the requirements has depth + stencil (this can heavily depend on the driver though) a driver can return that.
So you could say that it is a bug in the game as it should really ask for what it needs. Likely they didn't notice it because (most?) windows drivers return what they need anyway.
I'm not sure what to do about this. Perhaps we should sort the format list in some way but I wasn't able to discover a pattern in it.
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #48 from Roderick Colenbrander thunderbird2k@gmx.net 2008-03-31 07:54:20 --- My previous test was on a ati card. I just repeated it on my geforce7 and there I receive a pixel format without depth and stencil just like on Wine. Again I seem to receive the first pixel format available that matches the criteria. I haven't tried the serious sam demo on windows but I would expect issues UNLESS the nvidia driver contains fixups for this game.
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #49 from Tobias Jakobi liquid.acid@gmx.net 2008-03-31 08:17:53 --- Hi Roderick,
sorry for all the trouble. The problem really seems to be in the game engine.
Quote from http://www.tomshardware.com/de/nvidia-geforcefx-mit-dampfwalzendruck-in-die-...:
quote("Serious Sam does not specify a Z-buffer depth when enabling Z. By default, our driver will select the first Z-depth available, which is 16 bits. For the majority of the scenes in Serious Sam, 16 bit Z is sufficient. There are, however, a few areas where some Z artifacts can be seen.
You can force Serious Sam to specify 24-bit Z by doing the following:
(type "~" to bring the console)
gap_iDepthBits=24 ApplyVideoMode()
In this mode, the Z artifacts are eliminated (or greatly reduced). We have seen little, if any, impact on performance using 24-bit Z.
We have already addressed this with Croteam, and this issue is fixed in the upcoming patch, but the patch is only BETA right now.");
Using this in the ingame console solves the problem. Even setting iDepthBits to 16 produces a pixelformat with a 24-bit zbuffer. No more visual error, I think we can close this one.
Big thanks, Tobias Jakobi
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #50 from Tobias Jakobi liquid.acid@gmx.net 2008-03-31 08:32:43 --- I added the bug to all Serious Sam (1) games in the AppDB and further added a comment about how to fix the problem.
http://bugs.winehq.org/show_bug.cgi?id=11970
Jan Buecken jb.faq@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID
--- Comment #51 from Jan Buecken jb.faq@gmx.de 2008-03-31 08:35:03 --- Tested what Tobias said in comment 49, he is right,
hence I set this bug to invalid, initially.
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #52 from Leslie Viljoen leslieviljoen@gmail.com 2008-03-31 10:05:36 --- But the regression occurs in Sacrifice too!
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #53 from Roderick Colenbrander thunderbird2k@gmx.net 2008-03-31 11:05:05 --- Sure Sacrifice might be broken due to the same patch but I think it is a very different issue as the game uses directdraw/3d. Most likely something needs to be changed in wined3d for it.
Regarding serious sam I might be able to fix it in Wine after all. It might be that I should refine our pixel format selection a bit and directly return when there is a match assuming we aren't doing this already (I forgot how I exactly rewrote this code).
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #54 from Roderick Colenbrander thunderbird2k@gmx.net 2008-03-31 15:22:46 --- I have sent a patch which should fix Serious Sam.
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #55 from Tobias Jakobi liquid.acid@gmx.net 2008-03-31 16:07:25 --- I would really like to test the patch but I'm unable to download anything.
http://www.winehq.org/pipermail/wine-patches/2008-March/052528.html <- you mean this one, right?
I'm not subscribed to the list and the scrubbed attachment isn't accessible (it's zero bytes).
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #56 from Tobias Jakobi liquid.acid@gmx.net 2008-03-31 16:13:48 --- Nevermind, found it! :-)
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #57 from Jan Buecken jb.faq@gmx.de 2008-03-31 18:24:25 --- Hi, just I checked out the newest git and applied the patch. I can cofirm that the patch fixes the bug with Serious Sam - TSE on a Nvidia Geforce 4 440 MX Go.
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #58 from Tobias Jakobi liquid.acid@gmx.net 2008-03-31 18:25:56 --- The patch doesn't fix the bug on a 00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02)
Tested with the Serious Sam TSE demo. Should I make some more logs? Intel drivers/hardware seems to behave even different than NV.
I can test this again on an Intel i915 when at home.
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #59 from Roderick Colenbrander thunderbird2k@gmx.net 2008-04-01 02:56:54 --- Created an attachment (id=11779) --> (http://bugs.winehq.org/attachment.cgi?id=11779) test case for use on windows
Could you try this test program on Windows on the intel card? On ati and nvidia drivers it said 'found'. It might be that the intel drivers on linux are sorting the pixel formats in a different way.
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #60 from Tobias Jakobi liquid.acid@gmx.net 2008-04-01 09:47:11 --- Sorry, I don't have a Windows installation. I might be able to find someone with an Intel card (i945 though) and test it there.
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #61 from Roderick Colenbrander thunderbird2k@gmx.net 2008-04-01 10:11:52 --- At least try to attach the glxinfo output of your intel card. Note that the patch is in git now.
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #62 from Tobias Jakobi liquid.acid@gmx.net 2008-04-01 10:20:43 --- Created an attachment (id=11785) --> (http://bugs.winehq.org/attachment.cgi?id=11785) glxinfo -t output
output from the i915 Intel card:
lspci: 00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #63 from Tobias Jakobi liquid.acid@gmx.net 2008-04-01 10:21:10 --- Created an attachment (id=11786) --> (http://bugs.winehq.org/attachment.cgi?id=11786) glxinfo -v output
output from the i915 Intel card:
lspci: 00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #64 from Roderick Colenbrander thunderbird2k@gmx.net 2008-04-01 12:07:15 --- The test failed on windows on a simple i84x card. I'm not sure why but I guess it is due the way the format list is sorted (I mean there is a format without depth/stencil at the top of the list, so that format is selected.)
It would be interesting to see what happens on a intel card + serious sam. I expect to see the rendering issues you had on wine.
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #65 from Tobias Jakobi liquid.acid@gmx.net 2008-04-01 12:59:31 --- Doesn't the TSE demo run on your system (the i84x one)?
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #66 from Tobias Jakobi liquid.acid@gmx.net 2008-04-01 13:02:25 --- Running the Sacrifice demo with the latest wine GIT snapshots shows the same Z-buffer problems like SS (I assume no Z-buffer is used at all).
Apart from the game looking horrible it seems to have similar issues, however I think that Leslie should open a separate bug for this one, or did he already?
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #67 from Roderick Colenbrander thunderbird2k@gmx.net 2008-04-01 17:19:46 --- It wasn't my intel pc, just one of a friend which I could quickly test. I can't install serious sam on it. The sacrifice issue should get its own bug.
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #68 from Tobias Jakobi liquid.acid@gmx.net 2008-04-03 07:51:07 --- Created an attachment (id=11826) --> (http://bugs.winehq.org/attachment.cgi?id=11826) test of the opengl32_crosstest
Test done on a Intel Mobile 945GM Express (thanks to Alex!)
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #69 from Tobias Jakobi liquid.acid@gmx.net 2008-04-16 16:07:36 --- @Roderick: Any news on this? It's kinda fixed for me now (as I can instruct the Serious Sam engine to force a z-depth), but I assume you wanted to create a fix that accommodates all GPU vendors, right?
Could a run of the SS demo on a Windows system help you figuring out how Intel drivers behave? I could try to convince Alex to give me access to her system once more (at least I hope I can.. *g*).
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #70 from Roderick Colenbrander thunderbird2k@gmx.net 2008-04-17 01:03:22 --- The code I added to wine's opengl was to match the behavior of windows opengl32. Our code behaved differently. In short there is a list with pixel formats and wine tried to find the best match while windows returned the first format which met the specified requirements. The format which is returned depends on the way the pixel format list is sorted. For nvidia the first compatible format supports depth/stencil on both windows and linux.
On a intel card on neither of the OSes the first compatible format doesn't offer depth/stencil. I expect the same bug in serious sam on windows using an intel card. It really is a bug in the game.
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #71 from Tobias Jakobi liquid.acid@gmx.net 2008-04-20 16:02:13 --- OK, so it would be better to do a final check on a native Windows system, right?
And if the problem also occurs there we simply resort to changing the Serious Engine config. My question however is: What if there are more applications of that sort? And what if this application doesn't offer any way to configure the parameters of the requested pixelformat?
Could a pixelformat "override" be a solution?
http://bugs.winehq.org/show_bug.cgi?id=11970
Clerc Mathias tlarhices@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tlarhices@gmail.com
--- Comment #72 from Clerc Mathias tlarhices@gmail.com 2008-04-20 18:16:52 --- I have the Z-order bug under WINE but under Windows XP the game runs fine. All done using an Intel graphic card.
http://bugs.winehq.org/show_bug.cgi?id=11970
--- Comment #73 from Roderick Colenbrander thunderbird2k@gmx.net 2008-04-21 01:02:40 --- Try that test app I gave. It can be that the format list is sorted in a different way and that's why you aren't seeing the error. There is no specific order in which the list must be sorted.
http://bugs.winehq.org/show_bug.cgi?id=11970
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #74 from Austin English austinenglish@gmail.com 2008-10-13 14:39:51 --- Closing invalid.
http://bugs.winehq.org/show_bug.cgi?id=11970
deckoff@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |deckoff@gmail.com
--- Comment #75 from deckoff@gmail.com 2012-05-25 07:42:34 CDT --- This bug is still active for me on thinkpad x220, intel integrated grapichs. lspci -v | less output :
00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09) Subsystem: Lenovo Device 21da Flags: bus master, fast devsel, latency 0 Capabilities: <access denied> Kernel driver in use: agpgart-intel
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller]) Subsystem: Lenovo Device 21da Flags: bus master, fast devsel, latency 0, IRQ 44 Memory at f0000000 (64-bit, non-prefetchable) [size=4M] Memory at e0000000 (64-bit, prefetchable) [size=256M] I/O ports at 5000 [size=64] Expansion ROM at <unassigned> [disabled] Capabilities: <access denied> Kernel driver in use: i915 Kernel modules: i915
00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04) Subsystem: Lenovo Device 21da Flags: bus master, fast devsel, latency 0, IRQ 41
Tried on clean prefix, via PlayOnLinix with different versions, including 1.4 , 1.5.4, 1.2.3 . On 0.9.55 ( which is stated not to contain the bug) graphics are fine
https://bugs.winehq.org/show_bug.cgi?id=11970
Alexey Kuznetsov axet@me.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |axet@me.com
--- Comment #76 from Alexey Kuznetsov axet@me.com --- *** Bug 48355 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=11970
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |t6zm3v62fkp7fe5@yandex.ru
--- Comment #77 from Gijs Vermeulen gijsvrm@gmail.com --- *** Bug 50507 has been marked as a duplicate of this bug. ***
-
wine-bugs＠winehq.org -
WineHQ Bugzilla