There are a few options I can think of which will provide you with AA, not necessarily on the same quality level as MSAA, but will generally work without causing any issues (and again, as a reminder, forcing MSAA into games that don't support it, especially when considering d3d9, is very much like asking for trouble or playing a game of Russian roulette):

• Using gamescope to render at a higher resolution (so a SSAA of sorts)
• Using any sort of SSAA or upscaling which can be enabled at driver level
• Using post-process AA with ReShade or vkBasalt
• Using a game's own exposed AA features (and yes, there are a lot of d3d8 and d3d9 games which include support for (MS)AA, but indeed not everything under the sun does. Most of the d3d9 games that do not have MSAA support at least will generally have a good reason for not including it. Such as making use of deferred shading techniques. Remember that in OG Oblivion you could not enable "HDR" and AA at the same time? Ever wondered why? The same concerns apply for d3d8, though the problem is arguably not that pronounced as in d3d9.)
• Using mods that make changes to a game's engine to ensure MSAA is properly supported

I know none of these are as convenient as toggling an option in dxvk, but sadly that approach rarely worked correctly, so we ultimately decided to remove it, after careful consideration. I apologize for the disruption to all the people who have come to rely on it, but honestly it shouldn't have been exposed in the first place, given the prevalence of the issues it can cause.

The option that DXVK used to have only worked with ancient games (basically games released before 2004).

If it were that simple, we'd have kept it around for d3d8 perhaps, but it's really not. Deferred shading has been used ever since 2001, so since the dawn of d3d8/programmable shaders really. It can work in some games that limit themselves to the fixed function pipeline only, but that's rather rare, and we can't know in advance which is which.

Forcing MSAA would work without issues in d3d7 and earlier games, btw, but of course that's besides the point with regards to dxvk.

There are a few options I can think of which will provide you with AA, not necessarily on the same quality level as MSAA, but will generally work without causing any issues (and again, as a reminder, forcing MSAA into games that don't support it, especially when considering d3d9, is very much like asking for trouble or playing a game of Russian roulette):

* Using gamescope to render at a higher resolution (so a SSAA of sorts)

* Using any sort of SSAA or upscaling which can be enabled at driver level

* Using post-process AA with ReShade or vkBasalt

* Using a game's own exposed AA features (and yes, there are a lot of d3d8 and d3d9 games which include support for (MS)AA, but indeed not everything under the sun does. Most of the d3d9 games that do not have MSAA support at least will generally have a good reason for not including it. Such as making use of deferred shading techniques. Remember that in OG Oblivion you could not enable "HDR" and AA at the same time? Ever wondered why? The same concerns apply for d3d8, though the problem is arguably not that pronounced as in d3d9.)

* Using mods that make changes to a game's engine to ensure MSAA is properly supported

I know none of these are as convenient as toggling an option in dxvk, but sadly that approach rarely worked correctly, so we ultimately decided to remove it, after careful consideration. I apologize for the disruption to all the people who have come to rely on it, but honestly it shouldn't have been exposed in the first place, given the prevalence of the issues it can cause.

Thanks for the answers guys! I just can't stand TAA & postFX implementations & the driver override SSAA doesn't apply whilst using dxvk. I do realise that some people would get confused why MSAA didn't apply in some games (deferred) but I still think the feature had use cases. I have at least 4 games that work perfectly fine with it but hey 😄 it was always an expensive feature & devs thought people would use driver overrides anyway that's why they didnt include an in-game option in the 00s. At least where MSAA is supported we can use samplerateshading 😁

And AMD's VSR is buggy as hell & the mouse scaling & windows UI stuff make it unbearable for an alternative SSAA option.

I do realise that some people would get confused why MSAA didn't apply in some games (deferred) but I still think the feature had use cases.

Simply not applying is rare in these cases. More often than not it would outright break rendering or at least glitch out in certain situations, making it hard for people to tell if it was an actual dxvk bug they were seeing or not. It was problematic to say the least. As @K0bin mentioned, the only way to keep it would have been to rework how it was applied, however that would have been both time consuming and challenging to pull off.

devs thought people would use driver overrides anyway that's why they didnt include an in-game option in the 00s.

No, it was either for technical reasons (it messed up deferred rendering, which was more important to have behaving correctly), or because it was rather expensive on the hardware at the time (mostly in the case of early d3d8 games).

I do realise that some people would get confused why MSAA didn't apply in some games (deferred) but I still think the feature had use cases.

Simply not applying is rare in these cases. More often than not it would outright break rendering or at least glitch out in certain situations, making it hard for people to tell if it was an actual dxvk bug they were seeing or not. It was problematic to say the least. As @K0bin mentioned, the only way to keep it would have been to rework how it was applied, however that would have been both time consuming and challenging to pull off.

devs thought people would use driver overrides anyway that's why they didnt include an in-game option in the 00s.

No, it was either for technical reasons (it messed up deferred rendering, which was more important to have behaving correctly), or because it was rather expensive on the hardware at the time (mostly in the case of early d3d8 games).

Completely understandable that it would be very time consuming for you guys 😁

Regarding the technical reasons yes that's what i had in mind cuz it was really expensive back then but it was possible to force it thru the driver or they didnt include it cuz it caused issues.

Thanks for the replies guys 😄

P.S.: Here's a screenshot of AquaNox on a Lunar Lake Intel iGPU. The game came out in November 2001 and supports 16x AA just fine.

"Older games had no support for AA" is not a good argument to make, the option was always on the table and it was up to the developers to decide if it's worth implementing or not. By not implementing it they were bound to make choices in their engines which would interact poorly to explosively with (MS)AA.

Thanks for the answers guys! I just can't stand TAA & postFX implementations

The option DXVK used to have did not work for all games that have TAA or post processing based AA anyway.

I was responding to winter when he proposed using TAA or post solutions hehe 😄

P.S.: Here's a screenshot of AquaNox on a Lunar Lake Intel iGPU. The game came out in November 2001 and supports 16x AA just fine.

"Older games had no support for AA" is not a good argument to make, the option was always on the table and it was up to the developers to decide if it's worth implementing or not. By not implementing it they were bound to make choices in their engines which would interact poorly to explosively with (MS)AA.

Oh for sure games had it but some just didn't give you an in-gane option even if it would work completely fine if you had the powah hehe 😄

I just found out about this feature and was very-very happy until I saw that it was recently axed. It would've been very useful for my Dungeon Siege playthrough that I'm doing. It's capped at 1024x768, and with mods it goes only to 1080p (but that makes the UI tiny). Basically the only option to get it to "scale" to normal resolutions without having having tiny unreadable UI on Windows is to use dgVoodoo2 wrapper which does exactly this: forces MSAA 8x and AF 16x and then forces the resolution that you need. It's actually such a common (well, "common") use-case that it even has it's own paragraph on PCGamingWiki: https://www.pcgamingwiki.com/wiki/DgVoodoo_2#HUD_and_interface_scaling_on_high_resolutions

But recent versions of dgVoodoo2 crash on Wine and the older one gives me stutters. Other AA solutions won't really do the trick in this case. Would've been really cool if I could get the exact same results without having to run Windows wrappers under Wine. I'll use the older version for now, but future users won't be as lucky, I guess.

Don't really understand the "users misuse it" argument. You're the maintainers, of course, so it's your right - just some feedback that it can be really useful for badly written older games (and users will misuse whatever they can anyway).

Don't really understand the "users misuse it" argument.

I have to admit it's getting rather tiring to address misconceptions over and over, but the main problem was that the way in which the option was applied was broken and could cause breakage in most games, not that users were misusing it. In truth, users were "misusing it" too, because they had the wrong expectations, but that stemmed from the fact that in itself, as an option, it was never a good idea to expose.

I am aware of the obvious benefits you see as an end user, because you're holding a nail in your hand and you obviously want a nice hammer to hit it with, even if that hammer can break apart when used or can hit your hand instead of the nail. If it works on some nails, the ones you care about, it would be perfect for you and that is the argument you are making. Sadly, we as "hammer manufacturers" can't give you a hammer that has all these problems we've always been aware of, even if it happens to work fine in several select cases.

Sadly, we as "hammer manufacturers" can't give you a hammer

I'd point out that on Windows NVIDIA control panel gives you the option of forcing MSAA per-application and has been doing that for pretty much forever - doesn't get more "hammer-manufacturer-y" than that - but I see you're not convinced by that.

the way in which the option was applied was broken

If it was enabled.

I am aware of the obvious benefits you see as an end user, because you're holding a nail in your hand and you obviously want a nice hammer to hit it with, even if that hammer can break apart when used or can hit your hand instead of the nail.

Yes, this is exactly what I want. I am firmly in the "power to the user, even if it breaks things sometimes" camp - that's why we use Linux, no? If it breaks a game (and the option is clearly named as something that can cause breakage to let the user know) - the user can just disable it, no harm done. Right now it's not labeled as something potentially dangerous, but that can obviously be changed.

I think #5093 has tons of very good arguments and suggestions of dealing with this in other ways besides outright removal. If it's marked/documented accordingly then you can even auto-close issues mentioning it - there is no unsolvable problem here. So I urge you once again to reconsider.

I can understand your point about the feature not belonging in the project, but as you know yourself - there are tons of other options that are basically hacks for poorly coded games - it's a bit too late for that. It would be a good argument for not implementing this feature, but it's not a good argument for removing something that users already use. IMO there really is no conceptual difference between forcing an aspect ratio and forcing MSAA - both are ugly workarounds that are sometimes needed - and yes, some games are not "adequately" playable on modern hardware without both, it's not just cosmetic.

I don't think I can say anything else that hasn't been already said, just adding one more voice to the feedback. I'll stop here, have a good day.

I'd point out that on Windows NVIDIA control panel gives you the option of forcing MSAA per-application and has been doing that for pretty much forever - doesn't get more "hammer-manufacturer-y" than that - but I see you're not convinced by that.

Our implementation was nowhere nearly as accurate as what's included in drivers, and hence broken, we've already mentioned that. So that's comparing apples to oranges, there's no convincing involved at all in the argument, it's purely factual.

I can understand your point about the feature not belonging in the project, but as you know yourself - there are tons of other options that are basically hacks for poorly coded games - it's a bit too late for that. It would be a good argument for not implementing this feature, but it's not a good argument for removing something that users already use. IMO there really is no conceptual difference between forcing an aspect ratio and forcing MSAA - both are ugly workarounds that are sometimes needed - and yes, some games are not "adequately" playable on modern hardware without both, it's not just cosmetic.

MSAA does not need to be worked around with hacks because it's not an essential functionality, it really is just cosmetic and always has been classified and marketed as such. You may subjectively feel otherwise, but we are discussing things from a technical point of view, not based on what people consider things to be or not. So is texture filtering for that matter, as an example, but as opposed to MSAA, forcing anisotropy levels doesn't cause issues in 99.9% of cases, so we're not against keeping that around.

The right way to address this, as you very aptly put it yourself, are the various mods and other tooling that are out there for people to use in this particular propose, and that are generally way more versatile than what was included in dxvk. Is it more of a hassle? Sure. Is it "not a valid option"? Only if you insist on it not being one or are particularly adverse to change.

I have no issue to take the rightful backlash for taking it out at this point, and I've already apologized for the inconvenience and offered several alternatives. It's essentially our fault for exposing something rather half-assed and broken in the first place. Nowhere in this process has the engineer in me ever doubted that it was entirely justified to remove it.

Just for the absolute records and fairness.. the per-game labels that NPI uses are just pretty much random placeholders.
You can see here what the AA flags did, and while some might still be hand-crafted for a specific case most of them are generic.