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

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.

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.

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.

*** Bug 31407 has been marked as a duplicate of this bug. ***

Still in wine-1.6-rc4-65-g6cf05f9

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.

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

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

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

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

Created attachment 47418 [details]
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.

Submitted as <http://source.winehq.org/patches/data/102231>.

Fix committed: http://source.winehq.org/git/wine.git/?a=commit;h=75d53c9aed0b93b5a3607d2949d04d0570e781b1

Closing bugs fixed in 1.7.12.

*** Bug 26819 has been marked as a duplicate of this bug. ***