http://bugs.winehq.org/show_bug.cgi?id=28869
Bug #: 28869 Summary: Neverwinter Nights fails to load Product: Wine Version: 1.3.28 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: opengl AssignedTo: wine-bugs@winehq.org ReportedBy: dj.shaw@btconnect.com Classification: Unclassified
Created attachment 37077 --> http://bugs.winehq.org/attachment.cgi?id=37077 Terminal output
Neverwinter Nights fails to load from wine 1.3.28 to 1.3.31
The videos play, then the cursor changes to the NWN hand, but the menu does not appear.
Regression testing gives
94ae743ea668e49d40ae4e2dc5fe1f5d9be018cb is the first bad commit commit 94ae743ea668e49d40ae4e2dc5fe1f5d9be018cb Author: Henri Verbeet hverbeet@codeweavers.com Date: Tue Aug 30 20:12:31 2011 +0200
ddraw: Make the OpenGL renderer the default one.
:040000 040000 fbce2dc172258a4a7eabc65b6f86bd58522b4667 dfb3b24196ac3ad09100758a48b2d4ef7e45e26b M dlls
This is the Diamond Edition as sold on www.gog.com.
http://bugs.winehq.org/show_bug.cgi?id=28869
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|opengl |directx-ddraw
http://bugs.winehq.org/show_bug.cgi?id=28869
GyB gyebro69@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression Status|UNCONFIRMED |NEW CC| |gyebro69@gmail.com, | |hverbeet@gmail.com Ever Confirmed|0 |1
--- Comment #1 from GyB gyebro69@gmail.com 2011-10-23 08:55:29 CDT --- I can confirm/reproduce the problem in NWN Diamond Edition on my system. The intro videos are playing fine but the main menu is black/nothing can be seen (music is playing). The problem is not reproducible in the demo version, because it contains only a small bik video, which doesn't come into play when launching the demo. Is it allowed to attach one of the short videos (company logo) here, so the problem could be reproducible with the demo as well?
Workarounds: 1. winetricks ddr=gdi 2. Remove all bik videos from the movies directory.
Fedora 15 x86 Nvidia 250 / driver 280.13
http://bugs.winehq.org/show_bug.cgi?id=28869
GyB gyebro69@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download URL| |http://www.fileplanet.com/1 | |17661/110000/fileinfo/Never | |winter-Nights-Demo
--- Comment #2 from GyB gyebro69@gmail.com 2011-10-23 09:09:32 CDT --- NVM, I found another way to reproduce the problem in the demo version. The demo installs CDpromoEND.bik in the movies directory. Rename that file to AtariLogo.bik. Start the demo by nwmain.exe. The logo is shown but the main menu shows only black.
http://bugs.winehq.org/show_bug.cgi?id=28869
Henri Verbeet hverbeet@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |94ae743ea668e49d40ae4e2dc5f | |e1f5d9be018cb
http://bugs.winehq.org/show_bug.cgi?id=28869
Vitaliy Margolen vitaliy-bugzilla@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #37077|application/octet-stream |text/plain mime type| |
http://bugs.winehq.org/show_bug.cgi?id=28869
--- Comment #3 from Henri Verbeet hverbeet@gmail.com 2011-11-16 12:07:43 CST --- I don't think I can fix this without moving GL processing into its own thread. What happens is that the application creates a GL context, makes it current, and then immediately destroys the DC that context was created on. This works more or less as long as that context stays current. However, when the application then also uses ddraw we have to make a different GL context current for wined3d. Since the original DC was destroyed, there's no way for wined3d to restore the original GL context after it's done.
http://bugs.winehq.org/show_bug.cgi?id=28869
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|directx-ddraw |directx-d3d
http://bugs.winehq.org/show_bug.cgi?id=28869
--- Comment #4 from GyB gyebro69@gmail.com 2012-08-05 02:30:37 CDT --- It is still present in Wine 1.5.9. In 1.5.10 the game hits bug #31407 for me.
I noticed that on my current system (Fedora 17, Nvidia 304.32 drivers), the previously mentioned workaround (ddr=gdi) no longer works for some reason.
http://bugs.winehq.org/show_bug.cgi?id=28869
--- Comment #5 from Alexandre Julliard julliard@winehq.org 2012-08-14 12:19:31 CDT --- *** Bug 31407 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=28869
b.w@gmx.tm changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |b.w@gmx.tm
http://bugs.winehq.org/show_bug.cgi?id=28869
Brandon Corujo haku08879@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |haku08879@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=28869
Frédéric Delanoy frederic.delanoy@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |frederic.delanoy@gmail.com
--- Comment #6 from Frédéric Delanoy frederic.delanoy@gmail.com 2013-07-09 03:57:09 CDT --- Still in wine-1.6-rc4-65-g6cf05f9
http://bugs.winehq.org/show_bug.cgi?id=28869
Pierre Etchemaite pe-winehq@concept-micro.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pe-winehq@concept-micro.com
--- Comment #7 from Pierre Etchemaite pe-winehq@concept-micro.com 2013-11-20 13:55:01 CST --- Problem still exists in 1.7.6
Debian unstable architecture amd64 Nvidia GeForce G102M / proprietary driver 325.15
Just out of curiosity I tried with 1.7.1 and CSMT patch, but no difference.
http://bugs.winehq.org/show_bug.cgi?id=28869
--- Comment #8 from Ken Thomases ken@codeweavers.com --- (In reply to comment #3)
Henri said:
I don't think I can fix this without moving GL processing into its own thread. What happens is that the application creates a GL context, makes it current, and then immediately destroys the DC that context was created on. This works more or less as long as that context stays current. However, when the application then also uses ddraw we have to make a different GL context current for wined3d. Since the original DC was destroyed, there's no way for wined3d to restore the original GL context after it's done.
I probably come off as WGL-extension-happy but we could solve this with an extension. Although wglMakeCurrent() requires passing in a DC, we could provide an alternative function which makes the context current with its last-used drawable(s). The X11 driver already stores sufficient information in the context object to do that. The Mac driver doesn't even require that. The Mac APIs separate the notion of making a context current for the thread from setting its drawable, so we can do just the former.
http://bugs.winehq.org/show_bug.cgi?id=28869
--- Comment #9 from Henri Verbeet hverbeet@gmail.com --- (In reply to comment #8)
I probably come off as WGL-extension-happy but we could solve this with an extension. Although wglMakeCurrent() requires passing in a DC, we could provide an alternative function which makes the context current with its last-used drawable(s). The X11 driver already stores sufficient information in the context object to do that. The Mac driver doesn't even require that. The Mac APIs separate the notion of making a context current for the thread from setting its drawable, so we can do just the former.
That's a good point.
https://bugs.winehq.org/show_bug.cgi?id=28869
Ken Thomases ken@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- URL|http://www.fileplanet.com/1 |http://www.gamefront.com/fi |17661/110000/fileinfo/Never |les/2129030 |winter-Nights-Demo |
https://bugs.winehq.org/show_bug.cgi?id=28869
--- Comment #10 from Ken Thomases ken@codeweavers.com --- I'm working on a fix along the lines that I suggested in comment 8. However, I've found that it's not enough.
There's a place in wined3d where it clears the current GL context without saving it so it can restore it later. At the top of wined3d_device_uninit_3d() there's a call to context_set_current(NULL). Just commenting out that call (with none of my other changes) allows the menu to show after the logo video.
(The logo video itself doesn't render for me. Neither does the game world. But the menu and the in-game HUD does. I'm testing with the demo download, as per comment 2.)
https://bugs.winehq.org/show_bug.cgi?id=28869
Ken Thomases ken@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ken@codeweavers.com
https://bugs.winehq.org/show_bug.cgi?id=28869
--- Comment #11 from Ken Thomases ken@codeweavers.com --- (In reply to comment #10)
(The logo video itself doesn't render for me. Neither does the game world. But the menu and the in-game HUD does. I'm testing with the demo download, as per comment 2.)
It turns out that the game world failing to render is because glu32 is still tied to X11. A hack similar to the one on bug 34398 fixes that, although the logo video still doesn't show.
https://bugs.winehq.org/show_bug.cgi?id=28869
--- Comment #12 from Ken Thomases ken@codeweavers.com --- Created attachment 47418 --> https://bugs.winehq.org/attachment.cgi?id=47418 Patch to fix
This removes the clearing of the GL context that loses the app's context unrecoverably. It was originally introduced with http://source.winehq.org/git/wine.git/commit/77face22d5365d94b9bfe614ed202692e1523593. It doesn't seem related to the rest of the stuff in that commit, but I may not have followed the logic.
There's a comment that the clearing was necessary to work around driver bugs, but doesn't elaborate. I'm tempted to revert this part of it and see what breaks so it can be fixed the right way and with the appropriate documentation.
https://bugs.winehq.org/show_bug.cgi?id=28869
Ken Thomases ken@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |matteo.mystral@gmail.com Regression SHA1|94ae743ea668e49d40ae4e2dc5f |77face22d5365d94b9bfe614ed2 |e1f5d9be018cb |02692e1523593
https://bugs.winehq.org/show_bug.cgi?id=28869
Ken Thomases ken@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
--- Comment #13 from Ken Thomases ken@codeweavers.com --- Submitted as http://source.winehq.org/patches/data/102231.
https://bugs.winehq.org/show_bug.cgi?id=28869
Ken Thomases ken@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |75d53c9aed0b93b5a3607d2949d | |04d0570e781b1 Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #14 from Ken Thomases ken@codeweavers.com --- Fix committed: http://source.winehq.org/git/wine.git/?a=commit;h=75d53c9aed0b93b5a3607d2949...
https://bugs.winehq.org/show_bug.cgi?id=28869
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #15 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 1.7.12.
https://bugs.winehq.org/show_bug.cgi?id=28869
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |n.c.necros@gmail.com
--- Comment #16 from Anastasius Focht focht@gmx.net --- *** Bug 26819 has been marked as a duplicate of this bug. ***