[Bug 15839] Games for Windows Live fails to initialize, resulting Fallout 3 crash

[wine-bugs at winehq.org]

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


Jeff Zaroyko <jeffz at jeffz.name> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |John-Whitlock at ieee.org

Will Robertson <kassah at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kassah at gmail.com

kjella79 at yahoo.no changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kjella79 at yahoo.no




--- Comment #57 from Jeff Zaroyko <jeffz at jeffz.name>  2009-03-22 21:47:48 ---
*** Bug 17827 has been marked as a duplicate of this bug. ***


--- Comment #58 from Wouter de Geus <benv-wine.org at junerules.com>  2009-04-06 10:00:17 ---
Created an attachment (id=20312)
 --> (http://bugs.winehq.org/attachment.cgi?id=20312)
Updated Patch for WineD3D to set Driver an Description for wine 1.1.18

Since the "Patch for WineD3D to set Driver an Description" patch didn't apply
anymore for the -git version, I updated it so it works again.


--- Comment #59 from Will Robertson <kassah at gmail.com>  2009-04-11 20:09:59 ---
Created bug#18011 with patch from "Updated Patch for WineD3D to set Driver an
Description for wine 1.1.18". This is a clean request for the exact feature
that this patch is for, to make it easier for devs to find, as well as for
other apps that may have a need to report as related to them.


--- Comment #60 from Jeff Zaroyko <jeffz at jeffz.name>  2009-04-11 20:29:18 ---
*** Bug 18011 has been marked as a duplicate of this bug. ***


--- Comment #61 from John Whitlock <John-Whitlock at ieee.org>  2009-04-12 02:38:46 ---
(In reply to comment #59)

The devs are very aware of this bug, but they've rejected the attached patch. 
They prefer that a good value is automatically picked for the device
description and driver name.  That's completely reasonable, but harder than the
registry override.  I'm working on it, and I'm sad we missed 1.1.19, but I'm
hopeful that this will be fixed in 1.1.20.

If you have a Windows box with Fallout 3 available, I could use some
information.  Please post the first few lines of  (Doc Folder)/My
Games/Fallout3/RendererInfo.txt.  On Wine, they look something like:

Renderer Device Information:
        Direct3D HAL
        Display
        RenderPath                      : BSSM_SV_2

On Windows, they'll look like:
Renderer Device Information:
        NVIDIA GeForce 7600 GT
        nv4_disp.dll
        RenderPath                      : BSSM_SV_2_A

Please include your OS (XP, Vista, etc.)


--- Comment #62 from knipl at in.tum.de  2009-04-12 03:20:41 ---
Created an attachment (id=20394)
 --> (http://bugs.winehq.org/attachment.cgi?id=20394)
RendererInfo.txt from Vista SP1

your efforts are very much appreciated. here is my rendererinfo.txt from vista
SP1. hope it can be of use.


--- Comment #63 from kjella79 at yahoo.no  2009-05-02 14:06:58 ---
Created an attachment (id=20871)
 --> (http://bugs.winehq.org/attachment.cgi?id=20871)
GeForce 8800 GTS on WinXP SP03


--- Comment #64 from kjella79 at yahoo.no  2009-05-02 14:34:06 ---
(In reply to comment #61)
> The devs are very aware of this bug, but they've rejected the attached patch. 
> They prefer that a good value is automatically picked for the device
> description and driver name.

Creating a situation where you must upgrade or patch/recompile wine simply to
update it with a currently unreleased card description is foolish. This does
not necessarily mean other changes to wine, for example new low/mid-class cards
could bring new combinations of existing capabilities. Since they obviously DO
rely on these magic strings, the best solution would be:

1. Check for manual overrides (your patch)
2. If empty, pick a good value automatically
3. Fallback to current dummy values

I realize they're pushing to make you write point 2. as well, but there's
absolutely no reason to reject having a manual failsafe, nor implementing that
one first before going for the fancy autodetection. Setting it manually could
be the testing method to update the automatic code with new cards. What am I
missing here?


-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.