Alan Chandler wrote:
If I cd to the directory in which the game is installed (ie ~/win/sierra/gpl) and then run
wine gpl.exe
The program starts and fills the whole of my screen with a single black window. It sits there until I move the mouse, at which time it exits.
I have just discovered that if I cd to the root of my c: drive (ie ~/win) and then run
wine c:\sierra\gpl\gpl.exe
The program starts and I get a 640x480 window with the correct startup screen (I have "Desktop" = "640x480" in my config file). It is NOT managed (even though I have "Managed" = "Y" in my config file). However the program appears to partially work - in that
a) The program responds to the mouse when I click on the correct parts of the screen,
b) It runs a race with computer AI cars when I tell it too.
Can anyone suggest why this subtle change might exist?
I can't think of *why* this is happening, but I can confirm that we've seen this with a few other programs, including 3DMark2000. I don't believe that it's an issue particular to the TG patch, but I don't know of any examples of this happening with, say, a pure OpenGL game that doesn't require the TG patch.
As far as the managed issue goes, when DirectDraw creates the full-screen window, it doesn't use tha managed flag, since there are some DirectInput related issues that cause problems unless the visible top-left of the full-screen window is at the top-left of the real screen. When you've got support for XVidMode, it shouldn't matter, since it should you into the appropriate mode automatically.
You can try turning off the OWN_WINDOW #define in dlls/ddraw/dsurface/user.c - doing that will cause the DDraw cooperative window to be used directly for full-screen access, as opposed to the window DDraw creates itself. This is known to cause issues with some apps, and looks bad with XVidMode since you see the window manager border around the top left of the screen and the bottom-right is chopped off somewhat.
[As an aside, the colours seem to be the negative of what they should be - but it could just be a completely wrong pallette, the program should respond to the keyboard, but all keys affect the underlying console window in which the game was started, and there is a multiplayer option where it should (at least) detect that I have a TCP/IP connection, but doesn't - can anyone say, are these known limitations of the transgaming patch?]
DDraw doesn't deal well with 8-bit mode and palettes right now, so that could be one explanation for the negative colors. As for the keyboard input, there are some subtle issues with the OWN_WINDOW stuff now that may be causing you problems. Again, try turning it off in the dsurface/user.c code.
Lastly, is the transgaming patch likely to be folded into the up to date CVS versions of wine anytime soon.
The D3D code won't be submitted until we have the subscriber levels we need to keep the project viable - but we're not comfortable enough with the current code to start taking anyone's money yet. Most of the rest of our work is already in WineHQ CVS.
-Gav