Implement scaling of rendered content to window/screen size

[Oschowa]

Hi,

currently when using nine to run a game with render resolution < window size the content is not streched/scaled to fill up the window, but only occupies a part of it. This happens with vanilla wine and proton, some examples of what i mean:

Now i don't know if nine-standalone is the right place to implement this, or if this is even feasible, but this works nicely with dx11 games running through dxvk, so I thought it won't hurt to ask.

edit: forgot to add: this also works with wined3d

[axeldavy]

This feature is supposed to be implemented, but it needs recent wine patch (which you have with this repository) and recent enough mesa (18.3 at least)

[Oschowa]

Ok, i did some more testing with mesa 19.0 and nine-standalone 0.5-dev-git. Using wine 4.4 with World of Warcraft 1.12 the scaling works correctly. With Vampire Bloodlines the main menu is unscaled, but when actually loading into the game everything but the UI seems to be scaled correctly. It looks like this:

Probably because the game is totally broken anyways, I don't know if this'd even work on windows.

Dragon's Dogma i tested with proton 4.2 and there the scaling doesn't work at all. So i assume the scaling requires wine > 4.2? If that's the case, feel free to close this and thank you.

[Oschowa]

Actually thinking about it again: the fact that the scaling works 100% correct with wined3d and Vampire probably means there is some bug in nine-standalone's implementation.

[dhewg]

Yeah, there's something that needs to be fixed on our side. I didn't yet hunt down what's wrong, but check here for my findings with workarounds: https://github.com/iXit/Mesa-3D/issues/101

[Oschowa]

I used binkw32.dll 1.8.23.0 and renamed the Vampire/media dir, and it renders correctly with game res = screen res.

[dhewg]

Can you build standalone from the resolution_mismatch branch and try with that? It fixes the vampire scaling for me (bink workaround is still required though).

What's the game from your first screenshot? Does it fix that too?

[Oschowa]

I'll test with that branch when i get home today. The first screenshot is Dragon's Dogma.

[Oschowa]

With that branch a quarter of Vampire's output is now stretched across the screen and a screenshot produces this:

The desktop was not actually visible, but appears in the screenshot. This is with wine 4.4 and "vampire.exe -full -width 1280 -height 720" on a 1080p monitor, my desktop is gnome/X11 if that matters. There is no change with Dragon's Dogma (proton 4.2).

[dhewg]

So vampire now works, it's just the screenshot that's borked?

[Oschowa]

No, all i could see was the quarter of Vampire stretched across the screen, and when loading into the game the UI does the same thing as before.

[dhewg]

Huh, well that's weird. It works for me no matter how I try to break it... I updated the branch again to add some more debug output. Please run it with WINEDEBUG=d3d9nine and pastebin the output!

[Oschowa]

https://pastebin.com/raw/hVxNCLtM

[dhewg]

I get:

0009:trace:d3d9nine:device_process_message WM_DISPLAYCHANGE 1280x720 -> 1920x1080
0009:trace:d3d9nine:device_process_message setting resolution_mismatch for non-extended
0009:trace:d3d9nine:device_process_message WM_DISPLAYCHANGE 1280x720 -> 1920x1080
0009:trace:d3d9nine:device_process_message setting resolution_mismatch for non-extended
0009:trace:d3d9nine:device_process_message WM_DISPLAYCHANGE 1280x720 -> 1280x720
[game gui show up correctly at 720p here]
0009:trace:d3d9nine:device_process_message WM_DISPLAYCHANGE 1280x720 -> 1920x1080
0009:trace:d3d9nine:device_process_message setting resolution_mismatch for non-extended

So for whatever reason that's still different on your setup.

Was that with plain wine 4.4 and mesa 19?

[Oschowa]

Yeah, plain wine 4.4 and mesa 19 (llvm8) from arch repos.

[dhewg]

I got the GOG version, which comes with the unofficial patch. Maybe that fixed something in that regard? Which version do you use?

[Oschowa]

Also the gog version but i manually installed the unofficial patch 10.3. But if you don't launch the game with "-game Unofficial_Patch", it's not actually enabled. You can check if it's enabled in the rightmost tab of the options menu, it should say unofficial patch there.

[dhewg]

Yeah, I did the same, just with 10.2. The game loader and some patches still are in use even without that cmdline. But anyway, shouldn't matter since we're both using the unofficial patch

[dhewg]

Does it work if you try other resolutions, like 4:3. Or try to enable WINE's virtual desktop in winecfg and try then

[Oschowa]

Will try later today when i'm back home. Any idea why it doesn't work with dragon's dogma. Won't it work with proton at all?

[dhewg]

No idea about that game, from the screenshot it looked like my patch could fix that too, but apparently it's another issue. Generally, proton upscales fullscreen games to the native resolution instead of switching the display resolution. Gallium 9 Standalone combined with mesa 19 supports that just fine. Does the game render correctly with vanilla wine?

[dhewg]

I pushed another patch to that branch to add more debug output, let's hope there're some hints in there. Please use that for another log like above.

[Oschowa]

Got the new logs with the updated branch:

1280x720: https://pastebin.com/raw/HRZRkpZf

1024x768 (also broken): https://pastebin.com/raw/AaZtFAMr

1280x720 with 1920x1080 virtual desktop: https://pastebin.com/raw/E7PBxuJj With a virtual desktop i get a 720p window which only occupies a quarter again when fullscreened, so for me it's broken in every configuration. I also noticed that i was actually using wine 4.5 for the last few tests.

[Oschowa]

Did some more testing with games on proton 4.2:

METAL GEAR RISING REVENGEANCE -> works as expected Valkyria Chronicles -> borked like Dragon's Dogma (fine with wined3d)

Also, wierdly, while retesting, Dragon's Dogma scaled correctly one time i launched it with nine but i can't reproduce it in any way, so there seems to be some randomness going on... Anyways, here a log of Dragon's Dogma: https://pastebin.com/raw/1qE9B8BQ

Would an apitrace be of any help?

[dhewg]

With the added debug spew it looks like this on my end:

0009:trace:d3d9nine:device_process_message WM_ACTIVATEAPP WA_INACTIVE
0009:trace:d3d9nine:DRIPresent_ChangeDisplaySettingsIfNeccessary changing display settings to 1920x1080
0009:trace:d3d9nine:device_process_message WM_DISPLAYCHANGE 1280x720 -> 1920x1080
0009:trace:d3d9nine:device_process_message setting resolution_mismatch for non-extended
0009:trace:d3d9nine:device_process_message WM_DISPLAYCHANGE 1280x720 -> 1920x1080
0009:trace:d3d9nine:device_process_message setting resolution_mismatch for non-extended
0009:trace:d3d9nine:device_process_message WM_ACTIVATEAPP
0009:trace:d3d9nine:device_process_message WM_DISPLAYCHANGE 1280x720 -> 1280x720

You're missing a WM_ACTIVATEAPP message, which would restore the fullscreen window to the correct mode. But no idea why, I can't reproduce this. Another tester on irc cannot either, it works nicely for us.

I added another path to the branch, which restores the window on fullscreen mode changes. Does that fix it for you?

[dhewg]

I'm not seeing any issue with dragon's dogma either: https://imgur.com/mUGUm5P.png And that doesn't show the symptoms that these patches would fix. I think it's something on your end, like the x11 display driver, window manager, compositor or something like that.

[Oschowa]

The new patch doesn't seem to change anything, but i found that i can make Vampire scale correctly if I minimize the game (just Alt-Tab doesn't work) and fullscreen it again. This workaround doesn't work with the games I tested on proton though. If this is an issue with my setup (plain gnome/X11, amdgpu-ddx from arch repos, no special config), then i don't know why it works flawlessly with every game using wined3d or DXVK and even with some games (WoW, Metal Gear Rising) on Nine...

Anyways, I very much appreciate you taking the time trying to get this fixed. If this really only happens for my for some strange reason, I'm ok with just manually switching the monitor resolution for the very few dx9 games where i'd actually would like a lower rendering resolution, but maybe you or someone else will figure out what's going on someday ;)

[dhewg]

I'm not saying this isn't a bug on our end, but so far I've no idea how that is going wrong on your setup. I still have something to improve to maybe fix it, but without reproducing it on my end is like finding the needle in a haystack.

There must be something you can do to fix it, and it'll help to hunt this down. Can you try vampire a fresh wine prefix? Maybe some winetricks verb interferes... Do you have other window mangers installed to test it there?

[dhewg]

Updated the branch again, any changes with that?

[Oschowa]

Thank you for continuing to look into this. My wine prefix was a unmodified (except for nine-standalone ofc) 32bit prefix. I will try with a new clean prefix, the updated branch and Openbox wm later today.

[Oschowa]

Trying again with a fresh wineprefix brought no changes, but both Vampire and Dragon's Dogma actually scale correctly with Openbox, even with the older version of the branch! So it must be something which gnome does, which causes nine's implementation to break. The updated version of the branch is still broken on gnome, unfortunately.

[dhewg]

Okay, good so far ;) But if wined3d works correctly with the very same gnome version it's something we can fix. We just need to find out what it does differently... Did you try toggling gnome's desktop compositing?

[Oschowa]

As far as i'm aware, gnome automatically disables the compositing if there is a full screen window. You can disable this behaviour by calling Meta.disable_unredirect_for_display(global.display) from looking glass (alt-f2 -> "lg"). I just tried this but it doesn't change anything.

[dhewg]

Which version of mutter are you using? I found some workaround in the proton source which point to https://gitlab.gnome.org/GNOME/mutter/issues/306

[Oschowa]

mutter 3.32.0+49+gb2d0184c6-1 https://www.archlinux.org/packages/extra/x86_64/mutter/

[Oschowa]

Thinking back, i remember having the same issue as dragon's dogam with bayonetta a while back when i was still on mutter 3.30.

[dhewg]

Just for the record: https://github.com/ValveSoftware/wine/commit/f19f1bc0243a7147059dd957ee6aa5dd27e193b4 https://github.com/ValveSoftware/wine/commit/653c5cfe45f382891d5e6cbb45e256b456bda231 https://github.com/ValveSoftware/wine/commit/c9d04dc4b422b2811d42a4eb5f21df17c7bb643d https://github.com/ValveSoftware/wine/commit/0c9c7edd17c9b3a3e8ed8f373b8849865c7434f6

[Oschowa]

Hmm, if proton has to hack around mutter issues this badly, i wonder why it works with vanilla wine and wined3d...

[dhewg]

No issues with debian's mutter 3.32.0-1, with x11 or wayland

[Oschowa]

Seems like arch uses a git version of mutter with some more patches applied. I just build upstream mutter 3.32.0 without any patches, but there are no changes with Vampire... Is debian's mutter patched somehow? If not, idk why you can't reproduce.

[Oschowa]

Also build plain gnome-shell 3.32.0, no changes...

[dhewg]

There are patches, but dunno if those make a difference here: https://salsa.debian.org/gnome-team/mutter/tree/debian/master/debian/patches

[dhewg]

Probably unrelated, but I have this amdgpu xorg conf:

cat /etc/X11/xorg.conf.d/11-amdgpu-mine.conf 
Section "Device"
    Identifier "AMDgpu"
    Driver "amdgpu"
#   Option "DRI" "2"
    Option "TearFree" "1"
    Option "VariableRefresh" "on"
EndSection

[dhewg]

My installed xorg packages/versions:

dpkg -l|grep xorg
ii  xorg                                   1:7.7+19                             amd64        X.Org X Window System
ii  xorg-docs-core                         1:1.7.1-1.1                          all          Core documentation for the X.org X Window System
ii  xorg-sgml-doctools                     1:1.11-1                             all          Common tools for building X.Org SGML documentation
ii  xserver-xorg                           1:7.7+19                             amd64        X.Org X server
ii  xserver-xorg-core                      2:1.20.4-1                           amd64        Xorg X server - core server
ii  xserver-xorg-dev                       2:1.20.4-1                           amd64        Xorg X server - development files
ii  xserver-xorg-input-all                 1:7.7+19                             amd64        X.Org X server -- input driver metapackage
ii  xserver-xorg-input-evdev               1:2.10.6-1                           amd64        X.Org X server -- evdev input driver
ii  xserver-xorg-input-libinput            0.28.2-2                             amd64        X.Org X server -- libinput input driver
ii  xserver-xorg-input-synaptics           1.9.1-1                              amd64        Synaptics TouchPad driver for X.Org server
ii  xserver-xorg-video-all                 1:7.7+19                             amd64        X.Org X server -- output driver metapackage
ii  xserver-xorg-video-amdgpu              19.0.0-1                             amd64        X.Org X server -- AMDGPU display driver
ii  xserver-xorg-video-ati                 1:19.0.0-1                           amd64        X.Org X server -- AMD/ATI display driver wrapper
ii  xserver-xorg-video-fbdev               1:0.5.0-1                            amd64        X.Org X server -- fbdev display driver
ii  xserver-xorg-video-nouveau             1:1.0.16-1                           amd64        X.Org X server -- Nouveau display driver
ii  xserver-xorg-video-radeon              1:19.0.0-1                           amd64        X.Org X server -- AMD/ATI Radeon display driver
ii  xserver-xorg-video-vesa                1:2.4.0-2                            amd64        X.Org X server -- VESA display driver
ii  xserver-xorg-video-vmware              1:13.3.0-2                           amd64        X.Org X server -- VMware display driver

[Oschowa]

pacman -Q | grep -e xorg -e amdgpu

xf86-video-amdgpu 19.0.1-1 xorg-bdftopcf 1.1-1 xorg-font-util 1.3.1-2 xorg-font-utils 7.6-5 xorg-fonts-encodings 1.0.4-5 xorg-mkfontscale 1.2.1-1 xorg-server 1.20.4-1 xorg-server-common 1.20.4-1 xorg-server-devel 1.20.4-1 xorg-server-xwayland 1.20.4-1 xorg-setxkbmap 1.3.1-2 xorg-util-macros 1.19.2-1 xorg-xhost 1.0.8-1 xorg-xkbcomp 1.4.2-1 xorg-xmessage 1.0.5-1 xorg-xrandr 1.5.0-2 xorg-xrdb 1.2.0-1 xorg-xset 1.2.4-1 xorg-xwininfo 1.1.4-1 xorgproto 2018.4-1

I have no xorg.conf, but enabling TearFree via xrandr didn't change anything.

[dhewg]

I'm running out of ideas... Pushed yet another patch to that branch to add more debug spew. Please attach logs of vampire and ddda, and I'll compare those to my output.

[Oschowa]

vampire (wine 4.5): https://pastebin.com/raw/vbM9TTCc

ddda (proton 4.2): https://pastebin.com/raw/mgYFdvu4

I should probably mention that ddda again randomly worked once. It worked maybe like 2 out of 40 times now. I never saw vampire working once though.

[dhewg]

So that ddda log is from a working state? Please add another one where it doesnt

[Oschowa]

No, the ddda log is from a broken state. I don't have a log of a working state and I don't know what triggers it or how to reproduce...

[Oschowa]

Got a log from a working ddda: https://pastebin.com/raw/qt5n0vYt

From what i can tell, get_drawable_offset and get_relative_position are both 0 0 for the working state and have some values in the broken state. Don't know what could cause this though, I don't do anything different when launching the game.

[dhewg]

That's suspicious, it means the X11 drawable has a parent on the broken run and not on the working run. On the other side, on the vampire log, there's no parent and its still broken. Maybe a red herring.