[d3d9] Add a modeHeightFilter config option

[WinterSnowfall]

I've tried to be as generic as possible about the filter, since the idea is to allow people to use it with other games in case they run across similar issues, however with the first 2 AquaNox games it's a particular pain point, because:

• The games won't start at all or crash on resolution change if too many modes are reported. Too many seems to be above a dozen total resolutions listed in the menu selection (unsure about how many modes that would actually translate to). Edit: It might actually work mostly fine up to 32 total resolutions (it's hard to be precise here, as it depends on the display).

• Initially we need to expose 640x480 because the games will default to that after install and also after any crashes. They are an absolute pain to get going otherwise.

• Refresh rates don't seem to matter as much here as the total number of resolutions. Based on observed behavior the game appears to pick the highest supported refresh rate for a selected resolution anyway. Also based on observed behavior, adapter formats are counted towards the limit (the games differentiate between 16 and 32 bit color depths).

What I've also tried and didn't work:

• Restricting anything below 640x480. Doesn't lower the mode count enough to matter.
• Forcing an aspect ratio kind of works, I guess. The game is designed with 4:3 in mind, but works just fine with 16:9/16:10 so it wouldn't be ideal to limit it to 4:3.

I'd also like to apologize for blaming ANV for any of the woes with these games. It wasn't ever at fault - it was the display. WineD3D also has the same problems with the games, in case anyone was wondering, so it's not a Vulkan specific issue by any means. It's just an excessive mode count that's causing issues (probably on native as well).

[WinterSnowfall]

I get this lovely message from AquaNox on my laptop without the PR, btw (also with WineD3D):

[K0bin]

Can't we add in 1440p and 4k by default?

[WinterSnowfall]

Can't we add in 1440p and 4k by default?

Well, my laptop certainly won't mind because it tops out at 1080p. I think it should be fine, but I'll test it on my main monitor/TV anyway (it's 4K). Maybe ultra-wides can still be a problem if too many aspect ratios are supported, but we'll live and see. I'll add them if nothing explodes on my end.

[pchome]

I have a few questions:

1. If there is a message window with WineD3D but not with dxvk then maybe there is another error in dxvk somewhere, where it should not return D3D_OK for example?
2. Is 16 bit color depths useful for something? This is something on the game side or dxvk side? Maybe it would be better to create an option to drop 16 bit modes. (like if (devMode.bitsPerPixel != GetMonitorFormatBpp(Format) || devMode.bitsPerPixel == 16) or something inside the loop (?))

P.S. I love topics about display resolutions as owner of not standard resolution monitors (16:10, 21:9(WFHD,64∶27)). Devs almost always relay on 16:9 resolutions in games, so very often there are tons of issues in games with other aspect ratios.

[WinterSnowfall]

If there is a message window with WineD3D but not with dxvk then maybe there is another error in dxvk somewhere, where it should not return D3D_OK for example?

I get the same message both with master dxvk and WineD3D. I imagine I'd probably get the same behavior even on native if I had Windows on that laptop (but I don't). My PR makes the game happy (enough) so that it goes away, in short.

Is 16 bit color depths useful for something? This is something on the game side or dxvk side? Maybe it would be better to create an option to drop 16 bit modes. (like if (devMode.bitsPerPixel != GetMonitorFormatBpp(Format) || devMode.bitsPerPixel == 16) or something inside the loop (?))

In this day and age probably not, but some games expect it as a baseline, especially games from the d3d8 and d3d9 era. I would not remove 16-bit support and leave in only 32-bit considering the sanity of the principle, because that may cause all manner of unplanned behavior in game code. These adapter formats have always been supported by drivers, there's no reason to remove them (or sweep them under the rug, as it were).

P.S. I love topics about display resolutions as owner of not standard resolution monitors (16:10, 21:9(WFHD,64∶27)). Devs almost always relay on 16:9 resolutions in games, so very often there are tons of issues in games with other aspect ratios.

Very well may be the case later on, but most d3d8/d3d9 games (at least the early d3d9 ones) were designed with 4:3 aspect ratios in mind and I'm always pleasantly surprised when stuff works outside of this period-accurate sandbox. Sometimes it doesn't because UI elements are not designed with much leeway (see the first 2 games from the W40K - Dawn Of War bundle, which are stuck in 4:3).

[pchome]

In this day and age probably not, but some games expect it as a baseline, especially games from the d3d8 and d3d9 era. I would not remove 16-bit support and leave in only 32-bit considering the sanity of the principle, because that may cause all manner of unplanned behavior in game code. These adapter formats have always been supported by drivers, there's no reason to remove them (or sweep them under the rug, as it were).

I mean optionally disable 16 bit modes for cases like this, not by default. Resolution filter option by itself can be very useful, but if in case of AquaNox and a few other games disabling 16 bit modes will help then it could be good alternative dxvk option.

EDIT:

offtop

Very well may be the case later on, but most d3d8/d3d9 games (at least the early d3d9 ones) were designed with 4:3 aspect ratios in mind and I'm always pleasantly surprised when stuff works outside of this period-accurate sandbox. Sometimes it doesn't because UI elements are not designed with much leeway (see the first 2 games from the W40K - Dawn Of War bundle, which are stuck in 4:3).

Yes, this is obvious part.
Another part is when I use 1080 it is not mean I use 1920x1080. If I use 1920x1080 borderless window (wine vd) it has nothing to do with my current or default display mode (2560x1080). Some annoying things happen when devs take the 1080 vertical pixels and then current/default resolution to figure out horizontal pixels. Sometimes they set borderless fullscreen mode with wrong resolution in mind or something similar. Last time I checked some related bugs was present e.g. in wine virtual desktop and proton's fullscreen hack.
fs-hack was rather unusable, gamescope would be better solution but later (NV), wine vd usually rather fine so I using it.

[WinterSnowfall]

I mean optionally disable 16 bit modes for cases like this, not by default. Resolution filter option by itself can be very useful, but if in case of AquaNox and a few other games disabling 16 bit modes will help then it could be good alternative dxvk option.

Understood your point, but that's functionally equal to disabling the R5G6B5 adapter format for the game (if we would list 0 modes for it). In the case of AquaNox 2, anyway, it doesn't seem to make any difference, much like refresh rates also don't really affect anything based on observed behavior. It might do something for the first AquaNox, but I don't see what benefit it would bring. Here or anywhere else for that matter. I don't think there's any game out there that has 16-bit color depth related issues and in terms of keeping the mode number manageable, the aspectRatio and heightFilter options should be plenty good.

[ViNi-Arco]

I would not remove 16-bit support and leave in only 32-bit considering the sanity of the principle, because that may cause all manner of unplanned behavior in game code. These adapter formats have always been supported by drivers, there's no reason to remove them (or sweep them under the rug, as it were).

Hey Winter Snowfall, I agree, and there are people interested in 16-Bit depth for performance, like this request to add 16-Bit to MESA, which has been added.

[K0bin]

and there are people interested in 16-Bit depth for performance

We're talking about running an early d3d9 game on Vulkan 1.3 capable hardware... 16 bit color depth won't do anything for performance and it's only one person who's weirdly obsessed about it on the Mesa GitLab.

[WinterSnowfall]

The entire discussion was around the 2 AquaNox games in particular, so I don't think anyone would care that much. I'm just not keen on removing support for something the games rightfully expect to be there, especially when we're already working around a situation they would have never gotten into on age-accurate hardware.

[doitsujin]

Bit late, but:

Wouldn't it be a better idea to just enforce a hard limit on the number of display mode we expose and then just show the first n modes? I'd assume that most people will want to play at native resolution anyway, and if the maximum number of modes is hard-coded in the game we should probably do the most reliable thing.

Can always add a different option later to let users force specific display modes if needed.

[WinterSnowfall]

@doitsujin I did consider it initially, however it's hard to enforce an overall limit because we're currently caching modes per adapter format. That's also how GetAdapterModeCount works in d3d9. Getting n modes per format also has the potential to complicate things - a previous and worse iteration of this PR removed support for A2R10G10B10 which helped but didn't bring down the mode count low enough to avoid crashing. Of course, the games have a problem with the overall mode count (but oddly don't seem to care about refresh rates).

Using a ridiculously conservative value for n might get us in a situation where we only expose one or two resolutions (because some monitors may annoyingly report n+1 refresh rates), which might be fine for the games but it would be a terrible experience for end users IMHO.

For example I use a 4K 30 Hz only TV panel and would definitely NOT like to be stuck with that mode only - I'll obviously pick 1080p 60 Hz.

[WinterSnowfall]

P.S.: Something I keep forgetting is that both games start set at 640x480 when installed and also reset to it after a crash. There are config files you can dig for but it's an absolute pain to get to them.

And, of course, if 640x480 somehow isn't supported the games just won't start (unless you mess about in config files). Wonderful, I know.

[pchome]

What about an safeModeResolution option? Which will be used in combination with other filters to ensure the specified mode will be preserved. Then just use 16:9 filter, because there is no ideal solution. People will find out how to override it.

[WinterSnowfall]

What about an safeModeResolution option? Which will be used in combination with other filters to ensure the specified mode will be preserved. Then just use 16:9 filter, because there is no ideal solution. People will find out how to override it.

Agreed there is no ideal solution, which is why I went with creating a config option which allows people to set whatever resolutions they want in conjunction with the aspect ratio filter.

Aspect ratio + resolution width should be enough IMHO to narrow down resolution support as flexible as possible without complicating things too much. You really can't know beforehand what the combination of driver + monitor will end up exposing in terms of modes, but this should be rather future proof.

The workaround for these particular games may be less than ideal, I'll admit that, but while I happen to have an interest in fixing these 2 janky games, this PR isn't only about that.

If the game workarounds are the problematic part here, I'm fine with dropping the built-in config options for the 2 games. At least modeHeightFilter will be there to use in case people run into trouble. Because there will be people who won't run into any issues with these games (or any other games) anyway, simply because their driver + monitor doesn't report all that many modes.

[WinterSnowfall]

I've had a long rethink about this and in all truth I admit it makes little sense to impose resolution height jank on people who may not have any issues in the first place.

For now I've left the config option in place, and whomever the issue affects can use something like:

d3d9.modeHeightFilter = "480,<replace_with_preferred_resolution_height>"

With the AquaNox games, when needed, or with any other games, really. The purpose of the PR is to give people options to decide on their own what to expose first and foremost.

Perhaps there is a way to make better and more reliable provisions in the future for hardcoded mode count situations (such as enforcing an overall mode count limit, like doitsujin has suggested), but I've yet to think of a good approach that would fit d3d9's harebrained way of handling modes mixed with adapter formats.

[friedc]

I get this lovely message from AquaNox on my laptop without the PR, btw (also with WineD3D):

I have solved this by starting AquaNox (and also AquaNox 2) with GameScope. In Steam I use:

gamescope -f -w 2880 -h 2160 -r 60 -- %command%

[WinterSnowfall]

I have solved this by starting AquaNox (and also AquaNox 2) with GameScope.

Yes, that's also an option, along with xrandr-ing your way into blacklisting some resolutions you don't care about. But arguably the latter is more of a pain. Neither of these would work on Windows however.

A way to filter resolutions directly in dxvk would be a lot more user friendly and generally applicable, IMHO, hence the PR.

[K0bin]

Did the recent mode de-duplication commit make a difference here?

[WinterSnowfall]

Did the recent mode de-duplication commit make a difference here?

Nope, none whatsoever. There will always be a (small, but non-zero) category of older games that will simply break when too many modes are reported, and that's getting increasingly common with modern monitors.

[WinterSnowfall]

Ended up caching the forced heights, since there's no reason to reparse the option string if the queried format changes. I don't think I can make this any prettier, so it is what it is.

Some way of bringing down the mode count is still required to play AquaNox & AquaNox 2 on certain setups.

[WinterSnowfall]

I've refactored a bit and too lazy to rename 100 things, so will PR anew.