Linux gaming technical discussion

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

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
Click to expand...


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.

 
Hey, I just want to recap what I'm doing here, since I'm not sure how many of the suggestions apply to what I'm testing.  So here it is:

I'm going to be testing many 3D accelerated older games from the late 90s to late 2000s and besides seeing which I can get running, also see if I can force "real" antialiasing on.  (Either SSAA or mixed mode MSAA + SSAA for alpha textures).  These are going to range from DirectX 5 - DirectX 9 most likely.  If you're talking about enhancements beyond that, that's interesting, but that's beyond the scope for what I'm looking at this point.

Manoa: 

Several notes:

-I have an old AMD card that's slower than the 770, but I originally wrote AMD off, since my understanding was they got rid of the option to force AA in games at the driver level on Linux.  In other words, they removed the option to force AA (it had to be supported by the game itself), so I wasn't considering them for my test. Has that changed?

-I don't plan to be testing demanding games performance-wise.  My most recent game will probably be from 2009.  Is a Geforce 770 really not enough muscle to run 15-20 year old games on Linux?

-I'm not interested in shader based AA methods for this test.  Many of these older games are resolution-locked, so AA becomes the only method of cleaning up the image.  Shader based ones can help somewhat, but don't attack the worse elements of aliasing like shimmering and pixel-level flicker.  They mostly just smooth easily defined edges.  The idea behind this test is I'm trying to see if it's possible to get the games to look at good now as they could have in say, 2008.

-I have to definitely disagree with your claim that SSAA can't be done on a 770 with a playable framerate as I've literally done that on WINE with playonlinux last year.  Remember, I'm talking about a lot 15-20+ year old games, the polygon count just isn't that high.

-A sharpen filter could be of use if SSAA is working, but is blurry

I'm getting the feeling that you're trying to be helpful, but you may not be understanding the parameters of what I'm trying to test here.

cgalves:

-I'm not worried about integer scaling for this test, I figure that's something separate from game compatibility.  In other words, if it works, it can work on basically any game.

-Same for force feedback, I actually have that turned off on my own steering wheel anyway.

-I'm not going the custom resolution route that can send rates that the monitor can be incompatible with.  If the scaling can be done on the card / OS itself and it's downsampling the image to be sent back at native resolution, great.  If it involves forcing a monitor to try and take a higher resolution, I'm not doing that.  In addition to necessarily being good for the monitor, that's not a reliably reproduceable solution, it's too dependent on the monitor itself.

-You're honestly confusing me with what I should be running now.  Say I have a DirectX 8 game and a DirectX 9 game that's not in any Linux game database.  What steps would you recommend I take for:

1. Getting each game to run

2. Attempting to force antialiasing on said games.

For step #1, if it's the sort of thing where I should try method A first, then if that doesn't work, try method B, that's fine, but I'm a little lost as to the suggested path now.  In the past, I was using what I mentioned in the first post in this thread.  Apparently that's outdated now, so I'm trying to get my bearings.

 
Last edited by a moderator:
Ross Scott said:
-I'm not going the custom resolution route that can send rates that the monitor can be incompatible with.  If the scaling can be done on the card / OS itself and it's downsampling the image to be sent back at native resolution, great.  If it involves forcing a monitor to try and take a higher resolution, I'm not doing that.  In addition to necessarily being good for the monitor, that's not a reliably reproduceable solution, it's too dependent on the monitor itself.
Click to expand...
xrandr  '--scale-from' and '--transform' (transformation matrix) flags allow to scale screen buffer basically from any size to any size. Probably '--scale 0.75x0.75' will work too. 

I don't know how difficult it would be to set up on Ubuntu or such system. On Archlinux it should be pretty straightforward because you need to configure xrandr by yourself anyway )))  Sadly I don't have Arch at the moment and can't check this out. But I do know that when misconfigured the screen may become kinda blurry. So mb it could count as antialiasing... ? 

 
Nidhoggr said:
xrandr  '--scale-from' and '--transform' (transformation matrix) flags allow to scale screen buffer basically from any size to any size. Probably '--scale 0.75x0.75' will work too. 

I don't know how difficult it would be to set up on Ubuntu or such system. On Archlinux it should be pretty straightforward because you need to configure xrandr by yourself anyway )))  Sadly I don't have Arch at the moment and can't check this out. But I do know that when misconfigured the screen may become kinda blurry. So mb it could count as antialiasing... ? 
Click to expand...
Recommending Arch to non-Linux person is a terrible idea. And I say that as someone who used it for extended period of time and loves the system.

Many desktop environments have build in options for scaling, so that's probably better road to take. I'll try to look into Ross's post once I'm done with my work.

 
Prinny said:
Recommending Arch to non-Linux person is a terrible idea. And I say that as someone who used it for extended period of time and loves the system.

Many desktop environments have build in options for scaling, so that's probably better road to take. I'll try to look into Ross's post once I'm done with my work.
Click to expand...


Probably. But I can't say for ubuntu. I've never used it and I don't know which screen utility it uses and how. I just know that downscaling should be possible on linux.

 
Prinny said:
I'll try to look into Ross's post once I'm done with my work.
Click to expand...
Unfortunately, this is out of my field of expertise. I might be of some help if I were to help with specific results for specific title though as it's easier than dealing with more abstract problem.

 
> but I originally wrote AMD off, since my understanding was they got rid of the option to force AA in games at the driver level on Linux.

I would recommend you try both AMD and Nvidia cards/drivers.  Sadly forcing things like AA reliably seems to be outside primary goals of any vendor, so it's hit and miss regardless of the philosophy.

The AMD ones are first-class open source and do not come with a GUI configuration tool.  Instead they're compatible with the "standard" open source tools (xrandr, driconf, Xorg.conf, etc) as well as a wide variety of hacks & library replacements (libstrangle, etc).

The Nvidia ones come with a GUI tool, but replace several system libraries so other tools do not work.  The GUI tool they come with is basically the _only_ source of configuration you can do.  Also note the potential difficulties with older Nvidia cards (you will have to make sure the right [old] version of the Nvidia drivers are installed).

> If the scaling can be done on the card / OS itself and it's downsampling the image to be sent back at native resolution, great.

Yes, that's what xrandr --scale does.  The monitor does not even flicker (or notice), it's still being sent whatever resolution it was already set to.

N.B. xrandr is a standard X11/Linux tool for playing with screen resolutions, rotations, arrangements etc.  Many GUI monitor configuration programs use it (or the xrandr interfaces) behind the scenes.  It's not hard to use or learn, esp compared to many other command-line tools.  Will not 100% work with Nvidia drivers.

> I'm not going the custom resolution route that can send rates that the monitor can be incompatible with [...]  being good for the monitor

Note 1: not true with LCDs, their mux/decoder flatout rejects out-of-spec signals.  Some are more forgiving (eg allow more than a few % timing stretch) but that's about it.  Yes a potential problem if you are using a CRT.

Note 2: you won't be able to do this accidentally, adding new modelines to X11/Linux requires long commands full of numbers (and modeline calculator programs (unless you're crazy).  Not something to worry about unless you want to.

> Is a Geforce 770 really not enough muscle to run 15-20 year old games on Linux?

The "on Linux" factor is "it depends".  Some games run faster under Wine than Win, others visa versa.  Some stutter more, some less.  Also the variables of whether or not you are using dxvk & what graphics drivers (radeon, amdgpu, nouveu, Nvidia, etc) make a big different.  There is a whole stack of libraries between the game and your human peripherals that differs from Windows: wine .dll libs, directx->opengl (wine default) or vulkan (dxvk) shim libs, userspace opengl/vulkan (eg mesa), kernel opengl/vulkan drivers (eg radeon, amdgpu) and of course video card firmware.

I've been playing some Tony Hawks games under Wine on my desktop the past week.  THPS 4 has a horribly laggy level even on a good computer.  THUG2 runs a lot better.  These are games from 2000-2004 that may or may not be able to run faster than period computers because either of the different system stackup or perhaps in-built limitations, I don't have a fast system with period OS (XP) to test on.

> Say I have a DirectX 8 game and a DirectX 9 game that's not in any Linux game database.

That's most of the games I play :P I've got a folder of notes over the years of individual tweaks, methods or manual cracks I've had to implement for some more obscure stuff, I should probably write some of it up.

> What steps would you recommend I take for:
> 1. Getting each game to run

There is no one correct approach to step 1, other than:

1. Try
2. Furiously Google error messages
3. Ask for help on Wine forums or mailing lists if you can't proceed (I've had what I thought were impossible problems answered with simple magic.  Summon the gods of the d3dx8->d3dx9 shim dlls :D)

Some of the steps of my approach these days:

1. Create a fresh Wineprefix for each game, so installing arbitrary DLLs does not affect the other games I have.  If you're only starting then just ignore this step, learn it later when you start having issues.
2. Try and run and install the game.
3. If something goes wrong: check to see if the game is on WineHQ.
4. If not, google around.  Often the fixes required for playing the game on modern Windows also apply.
5. Run the game from the console, so you can see if it's spitting errors about a certain DLL or feature.  Often you just need to install some arbitrary windows stuff (d3dx9 libraries, etc).  Again, follow the fixes Windows users have to use.  Winetricks is a good shortcut program for getting & installing stuff.
6. Pull out the big guns.  WINEDEBUG=+dll,+reg wine program.exe and then lots of perusal.  Sometimes it's stupid stuff, other times it's multithreaded mayhem and I have no hope of working out what's going on.  When I get to the point of disassembling I know I'm lost and crazy.
7. Ask for help in a sqeaky voice on the WineHQ forums.  As per above, some nice people there :)

I don't use any of the GUI frontends (Lutis now?) so I can't comment on those.

> 2. Attempting to force antialiasing on said games.

Try all of the methods mentioned in this thread.   No single method will work everywhere.  Every game initialises and uses its graphics api (dx7/8/9/etc, opengl, glide, etc) in completely unique and arbitrary ways, what works for one will not work for another.  Things are less standard in the 3D world than you think, remember your custom 3D-in-every game programs?

The xrandr --scale option will "always" work (provided the game can be made to play at the higher resolutions it now thinks your monitor uses) but you will end up with tiny HUD+text unless the game is smart enough to scale these with resolution.  It will also potentially be the slowest, but I doubt rasterisation is going to be a bottleneck or FPS limiting factor for old games unless they are in a software-rendering mode. 

 
Last edited by a moderator:
Whilst I'm here:

http://dege.freeweb.hu/dgVoodoo2/dgVoodoo2.html

DgVoodoo is more than just a 3dFx->DX shim, it's also a DX(all up to 9?)->DX11 shim.  It lets you force certain things like AA, mipmapping, scaling and resolution.

Given that it's doing it at the graphics API level it's a good alternative to forcing things in graphics driver settings.   I used to only use it for getting 3DfX games working, didn't realise it also does directX.

 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top