Current Directory Strangely Affects Behaviour of Applications

[Gavriel State]

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 at transgaming.com