Re: user32,wined3d: move refresh rate fallback to catch all cases
On 25/06/07, H. Verbeet wrote:
On 24/06/07, Erik Inge Bolsø <knan-wine at anduin.net> wrote:
--- dlls/user32/sysparams.c | 13 ++++++++++++- dlls/wined3d/device.c | 10 +--------- 2 files changed, 13 insertions(+), 10 deletions(-)
What was the reason for writing this?
See the comments on http://appdb.winehq.org/appview.php?iVersionId=5618 ... essentially, I have a game that's hardcoded to request 1024x768x50hz, which is not available on my monitor, and the existing fallback to any available refresh rate in wined3d didn't catch it. Haven't traced the exact sequence of calls - but figured that since there was an existing refresh rate fallback coded, I'd move that a step instead of duplicating. I can try to trace it down and duplicate the fallback, if that would be a preferable solution. -- Erik
On 27/06/07, Erik Inge Bolsø <knan-wine(a)anduin.net> wrote:
On 25/06/07, H. Verbeet wrote:
On 24/06/07, Erik Inge Bolsø <knan-wine at anduin.net> wrote:
--- dlls/user32/sysparams.c | 13 ++++++++++++- dlls/wined3d/device.c | 10 +--------- 2 files changed, 13 insertions(+), 10 deletions(-)
What was the reason for writing this?
See the comments on http://appdb.winehq.org/appview.php?iVersionId=5618
... essentially, I have a game that's hardcoded to request 1024x768x50hz, which is not available on my monitor, and the existing fallback to any available refresh rate in wined3d didn't catch it. Haven't traced the exact sequence of calls - but figured that since there was an existing refresh rate fallback coded, I'd move that a step instead of duplicating.
I can try to trace it down and duplicate the fallback, if that would be a preferable solution.
-- Erik
Makes sense, I guess, although I'm a bit worried if that fallback is a proper solution in the first place. I suspect the game would fail on Windows as well if the refresh rate isn't available. Also, the 54Hz that's mentioned in the appdb page typically means you're using nVidia drivers with DynamicTwinView turned on (the default), which reports fake refresh rates.
On Wed, 27 Jun 2007, H. Verbeet wrote:
On 27/06/07, Erik Inge Bolsø <knan-wine(a)anduin.net> wrote:
On 25/06/07, H. Verbeet wrote:
On 24/06/07, Erik Inge Bolsø <knan-wine at anduin.net> wrote:
--- dlls/user32/sysparams.c | 13 ++++++++++++- dlls/wined3d/device.c | 10 +--------- 2 files changed, 13 insertions(+), 10 deletions(-)
What was the reason for writing this?
See the comments on http://appdb.winehq.org/appview.php?iVersionId=5618
... essentially, I have a game that's hardcoded to request 1024x768x50hz, which is not available on my monitor, and the existing fallback to any available refresh rate in wined3d didn't catch it. Haven't traced the exact sequence of calls - but figured that since there was an existing refresh rate fallback coded, I'd move that a step instead of duplicating.
Makes sense, I guess, although I'm a bit worried if that fallback is a proper solution in the first place. I suspect the game would fail on Windows as well if the refresh rate isn't available. Also, the 54Hz
Tested on an equivalent machine with windows xp; same graphics card/monitor combo ... it doesn't fail.
that's mentioned in the appdb page typically means you're using nVidia drivers with DynamicTwinView turned on (the default), which reports fake refresh rates.
Good point, thanks for that hint. Now the list of refresh rates looks much saner. Still no 50hz anywhere in sight, so I still need the patch. -- Erik perl: n. Programmeringsspråk best beskrevet som en noe elastisk gaffateip med pigger og skjærekanter.
participants (3)
-
Erik Inge Bolsø -
Erik Inge Bolsø -
H. Verbeet