Linux gaming technical discussion

[qptain Nemo]

9 hours ago, Ross Scott said:

•What's the advantage to using Lutris over PlayonLinux for DX5 - DX8 games?  Also, many of the games I'm testing are a little less common, I tried typing in a dozen titles of games I was going to test that didn't even have entries in the Lutris database.

 

•Maybe qptain Nemo could assist with this also.  Are there any games that give better results with dgvoodoo under DKVK?  I think you use it to tell it to render the game under DX11, but whether it works with the specific game is another question.

Regarding using Lutris for DX5-8 games: well, it provides you with a lot of useful configuration options per game that are easy to change quickly but if you don't need that then you can do without Lutris.

 

Regarding dgvoodoo + dxvk: I'd say, at least in some cases, yes. It supports games up to DX 8.1. See for yourself: an imgur album is worth a thousand words.

Couldn't get it working with: Need for Speed 3, Vampire the Masquerade: Redemption.

Also I kept the "apply Phong shading when possible" option on all, as well.

Edited May 28, 2019 by qptain Nemo (see edit history)

[Veyrdite]

Wow, quite a bit of info here.  I can offer some advice in other areas as I (unfortunately) have quite a bit of experience getting things working on Wine.    If you know what a 'debugger' in then you can have a taste of my latest hellish story (on the plus side: it now seems that all of the W3Dhub games now work on Wine).

 

A note about drivers, ATI vs Nvidia

 

I'm a staunch ATI person on Linux.  AMD moved their driver development away from their proprietary drivers (Fglrx/Catalyst) and onto the open-source ones (Radeon, AMDGPU) years ago, so now the open source ones (the ones you get by default on Linux, zero effort) are absolutely amazing.  Extremely stable, feature-complete and fast.  It used to be so much worse, trust me.

 

Nvidia are still sitting on their proprietary drivers (NVIDIA), with the open-source community effort (nouveau) getting little/no help and so still being pretty crap (despite the best & probably tireless efforts of the devs).

 

Proprietary drivers interfering with other tools/features

Spoiler

 

If you are using any form of proprietary driver: it may interfere with standard Xorg utilities such as xrandr.  They typically want you to use their proprietary GUI application for configuring screens instead.

 

Please comment if it causes you issues.  I recall I used to have to force a larger virtual screen in a setting somewhere for FGLRX when I used to use that, otherwise I could not make my displays much bigger or have many of them side-by-side.  It ran out of pixels

 

 

Driver-level FPS/performance overlays

Spoiler

The Radeon and Nouveau drivers use some shared code called "Gallium" that can provide driver-level overlays for performance monitoring.  Here's an example:

 

    GALLIUM_HUD=.c120fps,.c32frametime wine Game.exe

 

 

These overlays have a lot of options, including tracking stuff like drawcalls and poly counts.  Above I've chosen fps (with a graph cap of 120) and frametime (graph cap of 32-ish).  To see all of the options run:

 

    GALLIUM_HUD=help glxgears

    GALLIUM_HUD=help any_program_that_uses_opengl_here

 

(Of course under wine DirectX calls get converted to OpenGL calls by Wine, so any directx game also works.  The shots above are from Interim Apex)

 

 

Xrandr: upscaling and downscaling

 

xrandr is the standard Xorg utility for managing screens and displays.  Resolutions, refresh-rates, orientations, arrangements, etc.  I use it instead of any GUI tools for arranging & setting up my monitors because (IMHO) it's simpler and more predictable.

 

Sidenote: you can add your own modes (resolutions + refresh rates), something that I used to use to try and push my monitors to slightly higher rates (eg 60->72FPS).  Every monitor has different tolerances, some are much nicer than others.  Not covered here.

 

First you will want to familiarise yourself with Xrandr.  Run it without any options and it will dump your list of displays + their supported resolutions:

** I can't paste here, it makes a mess.  there's no option in the forum replies for monospace text or code anymore?  What? **

 

I typically use xrandr like this:

 

    xrandr --output DVI-0  --mode 1920x1080

    xrandr --output DisplayPort-1 --right-of DVI-1

 

Today we're going to use it to perform monitor scaling.

Upscaling: low-res games pixel-perfect

Spoiler

 

Quote

Sorry for hijacking the thread, but if there's any info on how to turn off billinear filters \ get pixel perfect scaling (I forgot the term for it), it would be nice to have some info on it, it would be useful for games like StarCraft, where the game is just a blurry mess. 

This is my particular method.

 

Essentially what we want is:

• Game provides a low resolution image
• We get our computer to nearest-neighbour (pixel-perfect) scale this up a few times
• We get our computer to then place this scaled version on the picture to send to a monitor, already in its native resolution
• The monitor displays a native-resolution picture

ie the monitor does not perform scaling, we do, and we have full control over it.

 

 

If you try and use xrandr's scaling function you will find it provides crappy bilinear scaling by default:

 

    xrandr --output DisplayPort-1 --scale 0.5x0.5

 

Appalling!

 

Xorg is perfectly capable of proper nearest-neighbour scaling, it's just that the xrandr utility doesn't give you an easy way to use it (unless you like writing out your own matrices).  There's a patch to fix this, but patching a popular moving target can be a pain.

 

Luckily someone else has a patched copy of the code handy.  It took me less than 5 minutes to:

 

    git clone git://anongit.freedesktop.org/xorg/app/xrandr

    cd xrandr

    ./autogen.sh

    make

 

Note that I'm not installing this copy of xrandr system-wide by running 'sudo make install'.  I already have a system-wide copy of xrandr and I don't want them to fight for supremacy.  Instead I go back to this folder and run this special copy of xrandr from here whenever I need it.  Which method you use is up to you.

 

I also had to install a 'xorg-util-macros' package, otherwise the compilation process complained these macros were not available.  Your distro will have this package under a different name.  You'll also need things like git, gcc, autotools, xorg-devel.  If you are on a Debian-based distro (like Ubuntu or Mint) you can probably get most of this by "sudo apt-get install build-essential".

 

Now that that is all done:

 

   ./xrandr --output DisplayPort-1 --scale 0.5x0.5 --filter nearest

 

 

Ooh, much better.  The blurriness in the picture is due to it being scaled down in my image editor + jpeg, in reality it's razor-sharp.

 

   ./xrandr --output DisplayPort-1 --scale 0.25x0.25 --filter nearest

 

 

*melting at the knees*

 

 

As you go to really high divisors (eg 0.2 and below) you probably no-longer need to worry about your resolution dividing neatly.  ie you probably won't notice if every 5th pixel is 21 pixels high instead of 20 (for example).

 

 

Our next step is to prevent the game from changing our screen resolution (and ruining all of our work).

 

Open up winecfg and enable the "emulate virtual desktop" option.  Set it to the new divided resolution of your screen (eg 1280x1024 at 0.5x0.5 is 640x512).

 

Next set Wine's background colour to black, rather than the default Redmond-blue.  This is under the 'Desktop Integration' tab of winecfg.

 

Sidenote: you can also import Windowx XP Luna theming here if you want Others probably work too, I've never tested them.  Sadly the titlebar of windows does not get themed, but all of the widgets do.

 

Things should be good to go now.  Your game will not be centred on your screen, unfortunately, as the black bars will be on the right and bottom.  You may also need to make your wine-desktop window fullscreen (your window-manager should hopefully have a way of doing this, try right-clicking the titlebar). 

 

To disable all of this shenaniganry:

 

    xrandr --output yourdisplay --scale 1x1

 

Ask for help if you need it.

 

 

Downscaling: a dirty way of forcing full AA on games that refuse to support it

Spoiler

 

xrandr also supports scaling in the other direction:

 

    xrandr --output yourdisplay --scale 2x2

 

I use this to take screenshots of programs & things that are bigger than my screen.  It's really fun to turn your 1366x768 screen into something "higher DPI" than your friend's 4K laptop, just make sure they are not wearing their glasses and you'll be able to fool them.

 

Of course this method is not as efficient as things like MSAA, but it at least works.

 

Again you may want to enable wine's virtual-desktop feature to prevent your game from changing the screen res, OR it might work fine already (with the game detecting the new virtual res as an actual monitor mode), YMMV.  For games that only support a small list of resolutions the virtual-desktop feature will allow you to force black (blue by default) bars as per the last section.

 

 

Edited June 1, 2019 by Veyrdite (see edit history)

[Veyrdite]

Slowing games down

 

Some games can't handle your fast CPU.  I have some solutions that partially work or help, but no perfect solutions.

 

A perfect solution should be possible on Linux, as it's "just" a case of getting the kernel scheduler to only provide your game with timeslots every x scheduling slots or so, but I'm not aware of any pre-existing solutions to let you do that.

 

Examples games I've encountered include:

 

• Interstate76
  • Sky moves too quickly
  • Wheels glitch in/out of the ground (visual issue)
  • Game seems 100% playable, until you get to the mission where you have to jump over a bridge.  You can *never* make it with a high FPS.
  • As it turns out: higher FPS dramatically reduces your vehicle's max speed.   Dramatically.

 

• No-One Lives Forever (NOLF) 1
  • Cutscenes cut each scene too early
  • Long audio (speech) tends to get cut

 

cpulimit

CPUlimit is a tool that I think works by sending SIGSTOP and SIGCONT signals to your process.  ie suspend and unsuspending it very quickly.

 

It works, but it's ugly and takes some fiddling to get the numbers right.  It does not run at a high enough of a frequency to keep things nice & smooth to play.

 

libstrangle

Last time I tried: I didn't have luck compiling this myself and getting it to work.  Did it require special cross-compilation to make a 32-bit version when you are on a 64-bit OS?  Wine games are almost always 32bit, so you need a 32bit version for them.

 

cpufreq/cpupower

These tools let you manually choose your processor's frequency scaling levels and governors.  You can use them to force your cores to stay in their lowest speed.

 

On my laptop this works great, I can go down to 480MHz.  My desktop unfortunately only goes down as far as 1.6GHz, which is still too fast for some of these games, but it is still a noticeably and dramatic improvement.

 

If you want to record video whilst doing this: only change the frequency of one CPU core and look into how to make a process only use that core on Linux.  That way the rest of your cores run at full speed for your capture software + encoding.

 

Force software rendering

(MESA only, ie not proprietary graphics drivers)

 

The Mesa part of the driver stack has some pixel-perfect software renders included as a fallback.  You can force-enable them through one of Mesa's many flags (worthwhile skim-reading):

 

    LIBGL_ALWAYS_SOFTWARE=true  wine game.exe

 

YMMV.  Sometimes this is perfect.  Other times it's overkill and your FPS shatters.

 

 

Edited June 1, 2019 by Veyrdite (see edit history)

[Ross Scott]

Veyrdite: I have an older AMD card, but I initially disqualified AMD from the running since it looks like on Linux, they dropped all support for forcing Antialiasing on the driver level.  Downsampling is of course an option, but I'm not sure that applies to older games that may not support modern resolutions (if it does, let me know).  

 

Correct me if I'm wrong, but my research before led me to this conclusion:

 

Nvidia drivers = forcing AA only works on some WINE titles, it's hit or miss, have to test it.

AMD drivers = forcing AA USED to only work on some WINE title, it was hit or miss, so AMD got rid of the option altogether.

[Veyrdite]

> Downsampling is of course an option, but I'm not sure that applies to older games that may not support modern resolutions (if it does, let me know).   

Modern resolutions == higher resolutions or actual modern 16:9 ones?

 

While you don't need exact modern resolution suppotr you do at least needer "higher" resolution support for your game for this to work.  Any sort of much higher res windowed mode will do if you are happy to live with some black bars around the edges.

 

Another problem worth mentioning: HUD scaling   Many games keep text, HUD and menus 1:1 with the pixels.  Depending on the game this can be anything from a somewhat harmless nuisance (eg on-screen health and ammo in an FPS) to completely frustrating (inventory management).  

 

 

 

> they dropped all support for forcing Antialiasing on the driver level

 

Raining anisotropic fridges, it looks like the Mesa devs did drop the overrides:

 

> Some users don't understand that these variables can break OpenGL. The general is rule is that if an app supports MSAA, you mustn't use GALLIUM_MSAA.

> [...]

> In a nutshell, it does more harm than good.

 

I'm presuming Phoronix used them wrong, Phoronix's forum community kicked up a stink and the Mesa developers got sick of it.  Whilst Phoronix is a great resource it has some reasonably hellish forums & community.

 

 

There will always be ways of hacking this support back in through shim shared objects (same things as  'hacked' dlls for games).  Unfortunately I've only ever seen random bits of code that claim to do this, but never compile right or otherwise seem to work.

 

 

 

[Veyrdite]

... so I got thinking.  Wine provides a directX->openGL shim layer.  That layer would have to convert sampling config (AA) from one world to the other.  Perhaps I can fix this problem at the wine level?

I just gave it a whirl on my laptop, it looks like you can: there's a registry key called SampleCount that seems  to do the job.  You have to manually create the key (and its folder) with 'wine regedit', they are not there by default.

 

Before (no reg key) and after (SampleCount=4) on GTA San Andreas:

 

 

Note that transparent objects are still shite, but all other objects and terrain are much smoother.  I suspect all games will react differently.

 

This game supports AA natively, so it's probably a really bad example.  It might be forcing off the features that would fix the AA on the alpha blend/test textures (transparent wires and trees). 

 

@Ross Scott: name a few games of interest (that you have have particular troubles with and/or are interested in) and I'll see if I can get copies to give them a whirl.  I'm not a rich guy, so please don't ask for anything too new

 

Hope this helps.  

Sidenote that may be useful: the proprietary Nvidia drivers replace openGL libraries with their own versions, so you (unfortunately) have to fully uninstall the Nvidia drivers if you want to switch your cards out for an ATI/AMD one.  Just keep this in mind if you have any issues (eg no graphical environment, or a slow 1024x768 graphical environment) when you test an ATI card.

 

Edited June 10, 2019 by Veyrdite (see edit history)

[Ross Scott]

Everyone:  I recently saw this link about Ubuntu dropping support for 32 bit architecture.  Is this going to affect my testing in WINE in the future on Ubuntu Mate?

 

https://www.linuxuprising.com/2019/06/wine-developers-concerned-with-ubuntu.html

 

Veyrdite:

The GTA screenshot looks like a classic case of MSAA-only with no alpha texture supersampling.  The easiest solution (if possible) is to force full SSAA instead. Although this is assuming the wires are textures and not polygon models.  If that's the case, then it's some shader mess intefering with everything.

[cgalves]

@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).

[cgalves]

6 minutes ago, RaTcHeT302 said:

uhh well i had issues with 8-bit installers, or whatever they are called, not working on Windows anymore, so it'll likely have a major impact

 

but maybe wine is somehow built with that in mind? i don't know, personally it has affected me before on Windows, I don't see why it wouldn't on Linux, but someone who has used Linux + Wine more in depth should look into it

 

anyway you can always just use an older version of ubuntu mate? maybe? they are likely separate from the main ubuntu project though, so it's up to them to decide i immagine

 

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.

1 minute ago, RaTcHeT302 said:

man this whole thing is just, not really making me want to switch to linux 100%, i really wonder what it would take to get the Windows experience but better, operating systems as a whole are a giant mess

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.

[cgalves]

26 minutes ago, RaTcHeT302 said:

i don't mind having options, but when it comes down to operating systems, i would appreciate some stability above everything else, being forced to change OS out of the blue has a huge time cost and it almost negates the advantage of having more choices to me at least

 

it sucks that backwards compatibility is not being taken too seriously, compared to the new stuff - thank god for emulators, sorta

 

i like having options but to me these are all bad options, i have to cripple myself just to maybe get the experience i want, it sucks, i know these things can be done well and it's really frustrating to see years worth of work thrown away, just like this

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.

[cgalves]

1 minute ago, RaTcHeT302 said:

no i'm just lazy

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

[BTGBullseye]

I'm personally a fan of LMDE... Stable, but stays up to date at the same time. Supports anything that would work in Debian, plus it has a more Windows-like UI. I use it on 2 of my personal systems.

[Veyrdite]

Ross: Ignore Ubuntu's stance.  They have announced lots of bad decisions before and had to backstep later, or never gone through with them.  It sounds like the people who made this decision don't play games (luddites I say!).

 

Keep using whatever Linux distro you prefer.  If and when you encounter problems then (and only then) consider changing to one of the almost-identical-distros-with-a-different-name-and-colour-scheme that abound.

 

On 6/22/2019 at 11:10 PM, Ross Scott said:

The GTA screenshot looks like a classic case of MSAA-only with no alpha texture supersampling.  The easiest solution (if possible) is to force full SSAA instead. Although this is assuming the wires are textures and not polygon models.  If that's the case, then it's some shader mess intefering with everything. 

The wires are indeed alpha textures on large rectangular polys.  I think this game is too old to be a shader-mess, it's more likely some fixed-pipeline variant.

 

There are a few more reg keys in the doc I link that could have an effect, I'll give them a try.

 

On 6/22/2019 at 11:23 PM, RaTcHeT302 said:

uhh well i had issues with 8-bit installers, or whatever they are called, not working on Windows anymore, so it'll likely have a major impact 

 

but maybe wine is somehow built with that in mind? i don't know, personally it has affected me before on Windows, I don't see why it wouldn't on Linux, but someone who has used Linux + Wine more in depth should look into it

 

16-bit.  Ie games and programs from around the Win1,2,3,95 era. 

 

There are quite a few, as even into the reign of Win98 many games would still use 16bit executables to provide compatibility with older systems.  32-bit executables gave programmers a lot less headache (no 64K limit, proper memory management done for you, etc) but it was a still a new option.

 

I believe Windows has dropped supported for WOW64 (16 bit support on 64-bit windows) completely now.  On 32-bit versions you might still be able to enable it manually?  But on 64-bit I believe you are SOL.

 

The Linux world is unfortunately almost as bad at the moment.  Wine supports 16-bit executables perfectly, but you also need your kernel to support them.  This is an optional feature when the kernel is being compiled, to change it you have to recompile your kernel (easier these days, but still not something most ordinary users will want to do).

 

Different distros choose different options to compile their kernels.  I'm unsure what Ubuntu does (try it to find out), but I know my distro (Void) has it disabled.  If you are lacking 16bit LDT then you will get messages like this when trying to run old 16-bit Windows programs:

 

$ wine esheep.exe

[...]

0032:err:winediag:build_module Failed to create module for "krnl386.exe", 16-bit LDT support may be missing.
0032:err:module:LdrInitializeThunk "krnl386.exe16" failed to initialize, aborting

$

 

Once upon a time 16-bit LDT was enabled by default in basically all distros, then some security flaws were found in it and as a result many distros changed their build settings to disable it.  I've heard that the problems have since been fixed, but few distros have bothered changing the settings back. 

 

After all, who cares about old software?  Pfft!

Edited June 28, 2019 by Veyrdite (see edit history)

[Veyrdite]

On 6/23/2019 at 5:21 AM, BTGBullseye said:

I'm personally a fan of LMDE... Stable, but stays up to date at the same time. Supports anything that would work in Debian, plus it has a more Windows-like UI. I use it on 2 of my personal systems.

Ooh, thankyou for the suggestion.  The Mint installs on my folks' laptops are now ancient and I want something else to put them on.

[Jakokdybyholub]

That kill script can kill processes that are not wine related.

#!/bin/bash
sleep 30
for KILLPID in `ps ax | grep -i '.exe' | awk ' { print $1;}'`; do
  kill -9 $KILLPID;
done

killall -I -s KILL -v wineserver 

 

Problem is with the regular expression in grep command. The '.exe' will match exe with any prefix (the dot is special symbol for any character)

For example, on my system it could kill also these processes:

 

 2000 ?        Sl     0:00 /usr/lib/gvfs/gvfsd-trash --spawner :1.6 /org/gtk/gvfs/exec_spaw/0
 7739 ?        Sl     0:00 /usr/lib/gvfs/gvfsd-http --spawner :1.6 /org/gtk/gvfs/exec_spaw/1

 

For start, I would suggest to edit the script in this manner (adding backslash "\" to grep -i '\.exe')

#!/bin/bash
sleep 30
for KILLPID in `ps ax | grep -i '\.exe' | awk ' { print $1;}'`; do
  kill -9 $KILLPID;
done

killall -I -s KILL -v wineserver 

In this case, it will only match lines that contains '.exe'

But it would be much better to test if a process is wine releated.

 

Maybe changing the script to something like this would be enough:
 

#!/bin/bash
sleep 30

# kills currently running wineserver
wineserver -k

 

 

[testman]

Is there anything we can do to help Ross with the issues he is encountering in Linux?

[Ross Scott]

I've just been super busy, I plan to take another crack at it soon.

[Ross Scott]

Another question:

 

I've found a way to essentially have 2x2 SSAA for many old games on Windows.  If the game will run with dgvoodoo, I can force it at higher resolutions than it will normally run.  If I combine that with Nvidia's DSR (dynamic scaling resolution), I can pump the resolution higher than what my monitor runs at, essentially creating downsampling on the game and getting a cleaner image that way. 

 

Is there anyway to specify Linux or WINE to run at a resolution higher than the native one and then downsample to the native one?  In other words, if you had a 1080p monitor, could you tell a game to render at 4k, but then downsample the output back to 1080?

[Manoa]

I suggest expanding the test range to include the open source nouveau driver for nvidia hardware, geforce 770 is kepler architecture so it should be supported by nouveau, what makes nouveau special is the ability to run DX9 native directly in hardware, no translations to GL or VK, you may have to refer to your distro manual to figure out how to switch the display drivers to nouveau, but it's possible distro builds of mesa may not include nine support so you may have to compile the graphics stack yourself (recommended, and worth it ), one good thing about this option specifically for you because you wanne play less than DX9 games is boosting the games from pre-9 to 9, so for example you take say a DX7/8 games and using DX1-8 to 9 convertion you get "native" DX9 for pre DX9 games by boosting libraries

 

I am also looking for ways to have SS/MS in WINE/Proton+Nine

so far I only have the general nvidia operational phrase: "you gete blur and you get blur and everyone gets more blur"

but im getting there slowly one hack at a time

 

I would also recommend to try with the open source radeon stack, that is get a radeon card and see if anything changes (radeon is VASTLY superior to nouveau in open source driver stack terms, which could lead to improved results), I know this is not exactly what people usually whant to hear since this is money going out, but if it fixes the rendering problems...is worth it

 

I know you mentioned you don't like post "AA" but...it can look good when set to highest, I had very good results even at 2K(native) resolution with FXAA set to 39 in reshade (simply have to edit the shader code and uncomment), one more thing: a 770 can only go so far, performance is very limited, performing translations+applying exotic post shaders or AA not to mention supersampling and friends....can't be done, not at any normal framerate, you could mitigate this by compiling a fully preemptive kernel and set it's clock to 1000 hz, but even the lowest latencies cannot give you throughput...you just need more graphic resources if you really prefer to stick to nvidia I highly recommend a 780 Ti, a good one with high clocks like 1200 mhz on the core (such as the EVGA classified kingpin), it's expensive around 500$ (which is the same price since 2014) but it's the best there is. the problem is that radeon cards fail badly in windows and nvidia cards fail badly in linux, so if you buy a radeon card for linux and linux fails you, your windows experience will be compromized by radeon bugs (AMD is a small low-budget company and they cannot afford software development...) and if you buy a modern nvidia card you won't be able to drive it (by open source drivers) in linux at all. I cannot recommend using nvidia closed source drivers, not realy so much for the principle of it but more because nvidia has proven in the past to do dirty things, one such thing is proactively withholding firmware images to drive their modern hardware by open source nouveau driver, they are actively trying to force linux users to use their closed drivers...

 

I also recommend to test some winecfg DLL overrides for various DLL's and don't forget to install directX fully (download directX june 2010 and install it)

 

try xrandr --output yourdisplay --scale 2x2

but I think it might look bad, I haven't tested this yet myself

 

Edited February 14, 2020 by Manoa (see edit history)

[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...

 

12 hours ago, Manoa said:

I suggest expanding the test range to include the open source nouveau driver for nvidia hardware, geforce 770 is kepler architecture so it should be supported by nouveau, what makes nouveau special is the ability to run DX9 native directly in hardware, no translations to GL or VK, you may have to refer to your distro manual to figure out how to switch the display drivers to nouveau, but it's possible distro builds of mesa may not include nine support so you may have to compile the graphics stack yourself (recommended, and worth it ), one good thing about this option specifically for you because you wanne play less than DX9 games is boosting the games from pre-9 to 9, so for example you take say a DX7/8 games and using DX1-8 to 9 convertion you get "native" DX9 for pre DX9 games by boosting libraries

 

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.