Whole screen dims out when targeting capital ships

[PatTheMav]

Using v1.5.10 rc1 on stock XWA (GOG install) leads to the whole screen being dimmed whenever a capital ship (e.g. cruiser/star destroyer) is targeted. Once a fighter-class ship is targeted, the dimming is gone.

No additional patches were activated, but I've tested with the 60fps patch and still had the same result.

The issue does not appear when @JeremyAnsel's latest version is used.

[rdoeffinger]

Can you confirm that it does not happen with 1.5.9?
There are relatively few changes since 1.5.9 actually, and none look like a really obvious candidate (though there's one change I did that is only in my branch I need to look at more closely).

[PatTheMav]

Will do that in a bit - I'm currently trying to find out why XWAUCP makes cutscenes run at half their fps and music is gone from gameplay.. 🙈

Edit: So the video playback issue might be a side-effect of the timer hook that fixes the constant 100% CPU usage. Worth the tradeoff I guess.

As for my issue, it sounds like exactly what you talked about in this post: http://www.xwaupgrade.com/phpBB3/viewtopic.php?p=156377#p156377

[bguthrie1]

I don't have this issue with the latest ddraw. You can try using xwahacker to disable 32-bit rendering and see if that fixes it. But the ddraw was supposed to fix it regardless if that was checked or not.

[bguthrie1]

Scratch that, I had 16-bit rendering turned on. I turned on 32-bit rendering through xwahacker and I get the dimming issue posted above. I've tried various DDraw versions and it seems every version is affected except 1.5.7. Which is the version that was intended to fix this issue. Something changed between 1.5.7 and 1.5.8 that allowed this issue to occur.

[PatTheMav]

@bguthrie1 So possibly a regression starting with 1.5.8 then. It seems to work like a charm with XWAUCP, but I do wonder if it's possible to remove the timer hook to let the ddraw handle the frame rate limit and thus get fluid video playback. 🤔

[bguthrie1]

What timer hook are you referring to? You can try removing the refresh limit in the ddraw config to see if that helps.

[PatTheMav]

The one installed by XWAUCP - it essentially tries to achieve the same thing (reduce 100% cpu usage by inserting sleep calls in an otherwise endless loop), but a (known) side effect is that video frame rates are more or less halved.

[bguthrie1]

Ah thats the hook_time.dll which removes the frame limit in flight. You can try replacing hook_time.dll with my 60FPS hook and see if that has an effect.

EDIT: Hook_time.dll shouldn't be affecting concourse frame rates. The refresh limit option I stated above should fix the issue but if that fails try using my 60FPS hook.

[PatTheMav]

@bguthrie1 - thanks hadn't thought of just renaming the 60fps-hook to get it to load instead of the timer hook. It fixed the video playback rate without impacting gameplay frame rates. Now I just need to check CPU usage.

(BTW - I take it that even with all changed DLLs the game is still forward rendering? Because just enabling something like MXAO in reshade leads to massive frame rate drops when e.g. a space station or star destroyer is in view).

[rdoeffinger]

Sorry about that, there is no automated testing an I regularly mess up manual testing.
It seems one of the patches in 1.5.8 actually broke the previous fixes for 1.5.8 again and I tested it wrong and did not notice.
Could try out rc2...
xwing_ddraw_d3d11_1.5.10_rc2.zip

[PatTheMav]

@rdoeffinger Thanks! If @bguthrie1 doesn't beat me to the punch, I'll try and test it in a 2nd copy of XWA (thanks to his tip I have a well-working XWA installation with UCP working and don't want to revert everything on that copy).

[bguthrie1]

Works fine now. Thanks Reimar.

[rdoeffinger]

In the hopes that it is indeed fixed for real this time, closing.