Alien Isolation has very bad aliasing and none of the game's built-in anti-aliasing methods are very effective. This is even a problem on Windows but at least those users have the option of using a mod that adds TXAA. Sadly it's very Windows/D3D specific. The best available option to Linux users is to render at a higher resolution and downscale. The game does not allow this natively so you need to use xrandr's --scale-from option and I gather this works for NVIDIA users. No such luck on an RX 480 under amdgpu + Mesa. xrandr --output HDMI-A-0 --mode 1920x1080 --scale-from 3840x2160 I initially tried the above. The desktop (XFCE) scales correctly but the mouse is locked to the top-left quarter of the screen. Both Alien and Neverball start but only render in the bottom-left quarter of the screen. Neither allows you to select a resolution greater than 1920x1080. I then found an IRC log where agd5f said that you also need to add a mode for the new resolution, although this was in a discussion about upscaling. xrandr --newmode "3840x2160" 712.75 3840 4160 4576 5312 2160 2163 2168 2237 -hsync +vsync xrandr --addmode HDMI-A-0 "3840x2160" This gave the same result except that Alien did allow me to select 3840x2160. Doing so made no difference in fullscreen but in windowed, it actually did render at the correct size, albeit with added window decorations. Neverball was the same except that it doesn't allow you to choose the fullscreen resolution. Note that it has a hardcoded list of modes that only goes up to 2560x1440 so I had to hack the higher mode in myself. I've seen XFCE do weird things in the past so I also tried with Oroborus, a much simpler WM, to rule that out but it didn't make any difference. So in summary, it seems like it's nearly there but something's not quite right. Linux: 4.8.14 Mesa: 13.0.2 xorg-server: 1.18.4 amdgpu: d60ea478cf2215ded7e1acf5817a0dae07e54026 libdrm: 08257927231e4f51c38e1d2bdbb8db0c2d4aec40
I managed to wrench my daughter way from her pure Intel Ironlake laptop long enough to discover that this is not amdgpu-specific. I didn't test Alien Isolation but the rest was the same.
Now I understand that the --panning argument is also needed to prevent the mouse from being locked. Not entirely intuitive but okay. The games are still the same though.
I've looked at how SDL2 picks up the current mode in SetXRandRModeInfo and enabled X11MODES_DEBUG. It reports that the current mode is 1920x1080. The xrandr utility also puts a * against 1920x1080 but of course this is still the real mode in use by the monitor. Perhaps SDL2 should look at the screen as a whole instead of individual modes but that would screw up on multihead configurations. I am using Zaphod mode so there are two distinct screens. What is the right way to do this? Screen 0: minimum 320 x 200, current 3840 x 2160, maximum 16384 x 16384 HDMI-A-0 connected primary 3840x2160+0+0 (normal left inverted right x axis y axis) 527mm x 296mm panning 3840x2160+0+0 1920x1080 60.00*+ 50.00 59.94 1680x1050 59.88 1280x1024 60.02 1440x900 59.90 1280x800 59.91 1152x864 75.00 1280x720 60.00 50.00 59.94 1024x768 70.07 60.00 800x600 60.32 56.25 720x576 50.00 720x480 60.00 59.94 640x480 66.67 60.00 59.95 59.94 720x400 70.08 3840x2160 59.98
I just managed to get unigine valley and Xonotic-glx to work on R9285 + fluxbox using - xrandr --output DVI-D-0 --fb 3840x2160 --panning 3840x2160 xrandr --output DVI-D-0 --mode 1920x1080 --scale-from 3840x2160 TODO work out how to get back to normal, quit X being current method :-)
Should have read extra info before posting (I only saw first posts that went to ati list). I don't even have sdl2 and only a single screen - so not much use other than it seems to work without adding a fake mode.
Thanks for your help. Multihead isn't really a factor in my tests as Zaphod mode allocates an entirely separate screen for each CRTC. I only meant that any fix would need to take multihead into account. I now believe this is entirely an SDL2 issue. If I comment out the call to SetXRandRModeInfo in X11_InitModes_XRandR then everything works. I don't even have to add a new mode. Neverball correctly reports 3840x2160. Alien shows 1920x1080 in the options but it is actually rendering at 3840x2160 while in fullscreen. SetXRandRModeInfo's main purpose in this context seems to be to deal with rotation and yet I get the exact same result while rotated when the call is commented out. I wanted to try --rotate and --scale-from at the same time but I couldn't get them to play well together. I'll therefore file an SDL bug. Sorry for the noise here, it was the mouse locking that threw me off. If anything useful could come from this report, it would be an improvement to the xrandr documentation. It says you typically use --fb with --panning but I didn't use --fb at all. If you don't use --panning with --rotate or --scale-from then you can get some very odd results. When I tried it on my Intel desktop at work, mouse locking wasn't the only strange thing I observed. How about instead of this: > You typically have to set the screen size with --fb simultaneously. We have something like this: > This option is typically used in conjunction with --fb, --scale-from, or --rotate.
That xrandr --panning needs to be specified explicitly for this is arguably a bug, see bug 39949.
(In reply to Michel Dänzer from comment #7) > That xrandr --panning needs to be specified explicitly for this is arguably > a bug, see bug 39949. That bug report is a little incoherent but that does seem to be one aspect of it. I agree that you shouldn't need to give --panning as changing mode in a game while rotated preserves the original --panning value, leading to weird results.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.