[Bug 2885] Max Payne fails to start

[Wine Bugs]

http://bugs.winehq.org/show_bug.cgi?id=2885





------- Additional Comments From zarquon at t-online.de  2005-11-11 15:31 -------
Created an attachment (id=1336)
 --> (http://bugs.winehq.org/attachment.cgi?id=1336&action=view)
Wine 0.9 run with WINEDEBUG=+loaddll,+d3d,+opengl

------- Additional Comments From saulius.krasuckas at elst.vtu.lt	2005-10-11
11:08 -------
* Andreas wrote:
[...]

> | > (so after rm -rf ~/.wine) If not , please try on a fresh install.
> | 
> | Not a chance in hell!
> | If you seriously think I'll reinstall all apps that need registry entries,
> | among those rather fickly ones like the SoF series, you've got another
> | thing coming. If you can give me a list of potentially dangerous registry
> | entries, I'll check for those, but I absolutely, positively draw the line
> | at a fresh install.
>
> Hey, don't treat "rm -rf" in an absolute scale. :-)

I suppose you mean rm -rf / as root ;-). But just having to install all the
emulated apps would be bad enough...

> Fresh install can be tested without losing the old one.  Put the old one in a

> safe place and you are done.	In UNIX all stuff is files, so you just operate
on
> them in a way you like. :-P

I can move the configuration files or even the whole directory, that's
easy. The problem is that apps might fail for completely different
reasons then because registry entries that might have been introduced
during installation are no longer found, so there's no way to be sure
that sort of thing doesn't make matters a lot worse. Still, I did

> $ mkdir ~/BACKUPS
> $ mv ~/.wine ~/BACKUPS 
> $ wineprefixcreate

today and the MaxPayne demo failed with the same error. So no luck there,
and I'm back to my old .wine again.

> | > It seems at first it is loaded by x11drv, then unloaded, and then loaded
> | > again by e2_d3d8_driver_mfc.dll.	My Max Payne is demo v1.05.
> | 
> | That rings a bell: Bug 2725, which I also get when a 3D rendering context
> | (OpenGL in 2725) is destroyed and then immediately reopened (when it
fails).
> | This may even be driver-specific. 
> 
> If fresh "~/.wine" doesn't help, then add +opengl flag to the previous
> combination mentioned here and attach the output, please.

Done. Unfortunately the OpenGL driver isn't particularily talkative either,
but maybe those two extra lines give you further insight (I kind of doubt
it, though).

> And one wild guess: does switching a Desktop Double Buffering checkbox
(winecfg
> -> Graphics) make any difference?

Tried all combinations of desktop double buffering and desktop itself on/off
and it didn't make the slightest difference.
I'm pretty sure Wine currently uses undefined behaviour when destroying
hardware rendering contexts, so it works on some platforms and fails on others.

What I'd really like to know ATM: what kind of graphics cards and driver
versions do people use for whom the current system works?


-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.