cgalves

Hi @Ross Scott ! A lot has happened since you've last had a look at this, so there's been some exciting developments which I'll now try to summarize some highlights: D9VK got merged with DXVK. This makes setup for everything much simpler, as you don't need to separately maintain two different layers. Additionally, since version 5.0 DirectX 9 games run through DXVK in Steam's Proton. To override it use "PROTON_USE_WINED3D=1 %command%" in Steam's advanced launch options. Proton has Integer Scaling available out of the box. That's right! You can get some sharp ass pixels now. Just use "WINE_FULLSCREEN_INTEGER_SCALING=1 %command%" in Steam's advanced launch options. I've not personally tested this yet, but I'm fairly sure it should work in Lutris also (provided you use a Proton-ified version of Wine, at least). vkBasalt has been released and adds SweetFX-esque post-processing effects, including CAS and AA. It only works in Vulkan, but since almost nothing is using OpenGL now, it more or less works in 90% of games. The CAS feature is particularly impressive, and can really help out with some games that just have a blurry look, no matter what. Lutris now has built-in frame-rate limiting support. I'm pretty sure you still need to install libstrangle for it to work, but now you just need to input the desired framerate into a box in your launcher's System options. new-lg4ff is a new driver for Logitech Force Feedback wheels (G29 and older) that implements previously missing Force Feedback effects. It's still a work in progress, but it should help quite a bit for Wine games, that previously had missing Force Feedback. You can also now use the Oversteer GUI to configure your wheel. Regarding super-sampling, there's a couple of ways to go about it, but no sure-fire way as far as I'm aware. First, as @Manoa mentioned, you can use xrandr to increase your resolution (you don't necessarily have to use integer scaling either). You should be able to automate the resolution switching in Lutris, using the pre-launch script and post-launch script options. Downsides to this are that it won't work for all games, and your whole desktop will change resolution, not just the game. Your second option is to use a custom resolution. This can be done, either through making a custom EDID for your monitor, using Custom Resolution Utility in Windows, or by using xrandr to make a new modeline. I'm not super well versed in this, so I don't want to give you a tutorial that could have wrong information on it, but there's a few guides out there and additional info on the Arch Wiki if you're so inclined. This should work for all games, but has the drawback of being a little riskier, as imputing the wrong values to your monitor could damage it over time. Personally, I'd try using vkBasalt's CAS and seeing if I really need more than what that offers. Now, regarding nouveau and native DX9... While academically interesting, I highly disagree that native DX9 would be of any benefit. DXVK has been benchmarked as faster in many cases than native Windows + DX9, due to a combination of poor performance in modern drivers + better multi-threading afforded by DXVK. Using DXVK you can still using wrappers to bring DX7/8 to DX9 and subsequently Vulkan (which then allows you to use vkBasalt). Combine this with the bad performance nouveau provides elsewhere, and I fail to see the case for actually daily driving it. If you want open-source drivers, stick to AMD. Until Nvidia changes their ways, if you buy their cards, you have to use their drivers.

Then hold on until Valve says "this is the distro going forward" and install that.

The reason we have all these options is because they all fill different niches. If stability is your utmost concern Debian is the choice for you. It's probably the slowest moving ship in the Linux sphere (alongside RHEL and CentOS), and there are no sudden movements if you're on the stable branch. The downside to it is that you won't get the latest stuff anytime soon (drivers, kernels, etc), at least without sacrificing a little bit of the stability afforded. I should point out that stability isn't necessarily just the lack of crashes or bugs, rather it means your whole environment is unchanging in nature. Want the absolute bleeding edge at the cost of occasional bugs? You've got Manjaro, Arch, and OpenSUSE Tumbleweed. Want something in between? There's Linux Mint Debian Edition, Fedora, OpenSUSE Leap, etc, etc, etc. There's no one-size fits all, because everyone's needs are different. It sucks that we will lose Ubuntu in the coming months/years, but I'm certain that after this initial freak-out phase, we will all be better off than we were before the announcement. I've been here long enough to tell you that no matter what, Linux moves forward. Is this a roadblock? Sure, but it will quickly get resolved and we can get on our merry way forgetting it ever existed. Does this suck? Yes, but we all have months to decide what our best way forward is; more if you're on anything other than Ubuntu 19.04. Please correct me if I'm wrong, but it sounds like you're new to the Linux community. This whole thing sounds like it's the end of the world, but it really isn't. The differences between distros, more often than not are very minimal and migrating from one to the other is usually really simple - no more complex than installing the new OS, keeping your username, copying over the data from your last installation's /home directory (or just not overwriting your /home partition, if you kept it separate from the rest of your system), and installing your software. Judging by what Plagman said, they're probably working on guides for newbies to help them migrate to whatever the next target distro is, which will help a lot of folks for sure. Point is: this sounds really shitty, but it's not as bad as you're thinking. In the long term, it's a non-issue.

Not a possibility. They use the Ubuntu branding, and therefore must use the same repos. Independent projects, like Linux Mint of Pop_OS! might, but we'll have to wait and see. Ross doesn't really need to worry about it for now, but going forward (like a year or two from now), the best course of action is probably to use whatever Valve end up choosing next (my bet is OpenSUSE, but that could just be wishful thinking). RE: Wine. Wine needs the 32bit libs or else the software can't work. Any workaround on their end will either drop performance by like 90% or severely fuck with the system libs or be a nightmare to package. If the Canonical is dead set on keeping the current course, our best bet is to just use something else. It's messy because of how it was just dropped on us (think of the roach analogy in the latest FM), but I'm confident things will pan out fine. If you're already on Ubuntu or something Ubuntu based, you'll be fine for quite a while (19.04 support ends January next year, and 18.04 ends in 2023). If you're not, it's just a matter of trying out some not-Ubuntu based distros (use a VM or whatever) and see what floats your boat. This is where Linux really shines: if MS did this to Windows, you'd be fucked with no recourse; with Linux, you can just switch to a different distributor and act like nothing changed.

@Ross Scott The situation with Ubuntu has kind of been dropped on everyone very suddenly (Valve included, apparently), so don't be surprised if some of what I'm about to say is outdated tomorrow. While 32 bit architecture (as in 32bit processors) has not been supported for over a year now, that only meant installation to 32 bit machines was not possible. 32 bit software worked just fine, as the necessary libraries were still provided via multilib repos. What Ubuntu has announced, is that starting with the next version (19.10) they are dropping those 32 bit libraries entirely. This is probably due to their larger focus on IoT/Server, or maybe to follow in MacOS's footsteps. Regardless, almost everyone seems to think that this is being done prematurely by a factor of decades. Valve's Pierre-Loup Griffais, has announced a few hours ago that they won't be support future Ubuntu versions as a result. Judging by what he said in a Discord server, they're likely considering OpenSUSE as their next distro of choice (with Debian and Fedora also being in the running). What does this mean in the short term? For Ubuntu gamers, they'll probably have to consider moving distros, but still have plenty of time as support for Ubuntu 18.04 LTS only ends in 2023. For you, this probably won't have any impact even if you're using 19.04, as 19.10 won't be released until mid-October, which should afford you plenty of time to conclude your testing. If you consider permanently moving to Linux, however, it might also be good to look at other distros, to see what floats your boat, though that won't really impact your current testing (distro choice doesn't really matter here beyond driver and Wine versions). You could also wait to see what Valve pick and go with that. Either/or. I've been AWOL due to lots of IRL stuff getting in the way, so I'll try to catch up as soon as I can (seems like lots of cool stuff has happened while I was gone).

@qptain Nemo Thank you for the instructions on dgvoodoo, I'll have to try it out whenever I get the chance. In regards to the patch in question, I'm not fully sure if it does integer scale or just proportional stretch to full screen. Ross may correct me if I'm wrong, but I believe he was looking for the former, since it provides a sharper look. More info here. @RaTcHeT302 I wasn't aware of that issue on UE3. Is there a reliable way of telling which games run on which engine? I'd like to cross-compare the games I tested with what engine to better see where the issues I encountered lie. I had zero luck with FXAA, but I agree that a more bespoke solution would be nice. Unless we manage to make a fund for some programmer to design something to our exact criteria, our best bet is to probably make a feature request on the D9VK GitHub for some option to more reliably add AA in the middle of the rendering pipeline, rather than some endpoint defined by Lutris/Nvidia. @Ross Scott You're welcome! I'm glad I could be of assistance. As for your questions... It's hard to say, since these projects evolve so quickly. If you were to release the video tomorrow, I'd say probably not worth using in most games. If you were to release it 6 months from now, then the lack of forced AA might well have been solved by then. I'd say that at a minimum it deserves a mention, since (as my testing shows) the performance boost can be huge, leading to games that might've not been playable before being playable now. The advantages for Lutris aren't just necessarily on DXVK/D9VK being a lot easier to use. The whole interface feels newer and more modern, complete with the way you interact with Wine being done through drop-down menus, rather than messing with winecfg or wine registry. Then there's the inclusion of the Protonified Wine builds, which use patches made by Valve to improve game compatibility and performance across the board. The one click game installs are also a lot better than what PoL had, with tons more games available since the scripts are a lot easier to make. Lutris is also under more active development so new features get added fairly frequently (they recently added GOG integration!). The only downside I can think about Lutris vs PoL is that PoL had a nicer method for making new Wine prefixes, while Lutris's is a little more convoluted. I'd still say the other benefits outweigh that drawback, though. I hadn't really heard of dgvoodoo until this thread, but from their description, it seems like they're doing to DirectX 1 through 8.1 and Glide, what WOGL, D9VK and DXVK do to DirectX. Basically, taking instructions that might not have support on modern GPUs/Windows drivers, and translating them into modern DX11 instructions. I've yet to try it, but it's hard to say whether or not we'd have better luck with forced AA down that route. At that point you're taking code and pushing it through two translation layers, so all sorts of weird things could happen. Or it could all work perfectly with zero issues. I'll figure it out soon enough, I suppose.

@Ross Scott Apologies for the wait, but I tried to be very extensive with my testing. Sorry in advance for the long post. @qptain Nemo Thanks for your post, it adds quite a bit to what I'm about to detail in this. I'm interested in testing the dgvoodoo method as I tested something similar, which you can see in the "Other Games" section. Can you post instructions on how to set it up in Lutris? With the intro out of the way, let's get onto the meat and potatoes. Testing System and Methodology Games Tested Conclusions Sorry for yet another massively long thread. Hopefully all this testing can be useful and we can figure out where to go from here. @Ross Scott , please let me know if there's anything here you'd like a detailed guide on.

Alright. I'll run some tests and tag you in a post whenever I've got something.

D9VK has mostly focused on Shader Models 2 and 3, IIRC. Newer games (more likely to have built-in AA) are more likely to work better on it, ATM. SM 1 is next in line, though. I can test a variety of games, but can add a known odd-ball or two if you can name them.

I have a pretty big game library, so it's kind of hard for me to remember what games have what settings. Any outstanding examples you want me to test?

Short answer: yes. Long answer: D9VK operates similarly to what's already built into Wine, by translated D3D9 calls into Vulkan calls. It doesn't require anything special for setup beyond what I delineated in my previous post. If it doesn't take forced AA, it could likely be a bug as it's still in its early days of development. Assuming you're using Lutris, you don't need to mess with the registry, as you can simply use the Anti-Aliasing option under "Runner options".

Hello everyone. It's been a long time since I've used a forum, so forgive me if my etiquette is a little rusty. This post may get a little long, but I'd like to address as much as I possibly can with all the information I have. I'd also like to suggest that we put in explanations on every terminal command that we post on this thread, as that will make it a lot easier for newbies to understand what they're actually doing. I think the best way is to have a commented out part after the command, so we can roughly explain what we're trying to achieve. Now for the actual post... Wine, V-sync, and libstrangle Lutris Forced Anti-aliasing Old games and resolution DXVK and D9VK Phew. I think that's everything so far. Sorry again for the extra long post.