Current Directory Strangely Affects Behaviour of Applications
I am trying to debug a game called Grand Prix Legends, running on wine with the transgaming patch. If just spent all day getting nowhere in winedbg because I couldn't get hold of what the game was doing. 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? [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?] Lastly, is the transgaming patch likely to be folded into the up to date CVS versions of wine anytime soon. Alan alan(a)chandlerfamily.org.uk http://www.chandler.u-net.com
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 -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com gav(a)transgaming.com
On Sat, 10 Feb 2001 20:26:17 -0500, you wrote: ...
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.
OK - understand, I only allow my screen to remain at full resolution at the moment, and not change mode. Fundementally I am wanting to get the server mode of the game operational first so I am not too concerned about the lack of proper graphics support. In fact, the fact that I don't loose the whole screen to the game is of benefit in trying to debug.
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.
I am learning about DDraw as I go along with this project and I've barely started, so I don't immediatley understand what you mean here - but I am sure a bit of poking around will get me there soon :-) ...
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.
Again I don't quite understand - but I'll splurge through the code and see what I can pickup. At the moment, the big problem is as the game exits. Its got this rolling credits screen which in the normal game under windows lasts about 10minutes - running with debugmsg statements with wine a LOT longer. The only way to kill it in the real game is to hit return, and at the moment that doesn't work, and trying to kill things behind the scenes seems to get lots of knickers in twists.
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.
Firstly thanks for your advice and the patch. Secondly, something I didn't quite appreciate is it only being the D3D code that is outside of current wine. GPL has non D3D modes that I could try and use (it has its own software renderer - fine when its a server, and an OpenGL renderer, when I ultimately try and get the client side working - although I haven't got my Linux box stable with openGL yet! :-) ) Alan alan(a)chandlerfamily.org.uk http://www.chandler.u-net.com
On Sat, 10 Feb 2001 20:26:17 -0500, you wrote:
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.
'...
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.
I've tried that, but no joy, I don't get anything get any windows. Alan alan(a)chandlerfamily.org.uk http://www.chandler.u-net.com
participants (2)
-
Alan Chandler -
Gavriel State