Implement scaling of rendered content to window/screen size about wine-nine-standalone

[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: iXit/Mesa-3D#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:
ValveSoftware/wine@f19f1bc
ValveSoftware/wine@653c5cf
ValveSoftware/wine@c9d04dc
ValveSoftware/wine@0c9c7ed

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

[Oschowa]

Maybe, but Vampire is broken in a different way (quarter strechted across screen vs. only quater visible on the edge of the screen), so maybe they are seperate issues? I'm not familiar with how any of this stuff works in detail, so I can only make bad guesses, sorry ...

[dhewg]

v0.5 includes the resolution mismatch patch. Does a recent mutter work for you by now?

[leipero]

Not sure if this is related to this issue, but I will add the issue I'm facing now, I don't know when it started, but I know it was not an issue about year ago, it's not an issue with some other DX9 games I have and tested (rFactor for example), nor does it happen witn wine-d3d, only in nine.
Screens:

It makes mouse control inaccurate as well.

[axeldavy]

@leipero Is the issue present as well when you launch in windowed mode ?

[leipero]

@leipero Is the issue present as well when you launch in windowed mode ?

No, just full screen (in this particular game), however, I did found another game where ssimilar issue happens (NFS Hot Pursuit 2 using DX8toDX9), only on gallium nine. Another (potentially related) issue is that image looks blurry and low-res/textures, take a look:

EDIT: This happens on at least two different PCs. I did try standard workaround with window manager etc., nothing works, only way to make it scale properly is alt+enter, then to get it back into full screen and select from the gnome shell.

[dungeon007]

@leipero If you are using AMDGPU driver and X, make you have amd ddx from git and not release, it have some fixes there. I think it does not simply act correctly there since i think kernel 5.2 or something like that.
As for WINE i hate this patch, usual revert for me 🤣 : https://source.winehq.org/git/wine.git/commitdiff/70d842b106d3ccbb0a786a41474903bddc4ea879
That is since WINE 4.6, breaks some behavior and even perf here... i mean, just to give you few ideas. 🤣

[dungeon007]

And i mean lookat the history of xrandr.c:
https://source.winehq.org/git/wine.git/history/HEAD:/dlls/winex11.drv/xrandr.c
Not touched since 2016-04-20 until 2019-04-11 and suddenly first one breaks everything, to fix nvidiah blobie 🤣

[dungeon007]

BTW, first one and first and only patch there by Figura... specs says this, ha, ha, and i am saying that moon is dark, do you believe me? So, go and draw it as dark now so that nobody could see it 🤣
Yep, i hate this and sorry about that...

[leipero]

BTW, first one and first and only patch there by Figura... specs says this, ha, ha, and i am saying that moon is dark, do you believe me? So, go and draw it as dark now so that nobody could see it
Yep, i hate this and sorry about that...

Thanks for the tips, I will test it ASAP, however, I should point out that issue happens only with gallium nine, not with WINE D3D or DXVK. Will report back. And yes, I'm using AMDGPU and X (stable/release versions, not git), will try that as well.

[dungeon007]

Sure thing, i was driven by this:
"Not sure if this is related to this issue, but I will add the issue I'm facing now, I don't know when it started, but I know it was not an issue about year ago"
About kernel 5.2 or about 5.1 something changed in an amdgpu kernel driver how these windows behave.
I tried to bisect it back then AFAIR, but it was during merge so i gave up 🤣
Likely you wont see issue with something like kernel 4.19 and wine 4.0... but if you are going newer, some combinations might missbehave.

[dungeon007]

BTW, even that older wine 4.0 might look borked if everything else like kernel and ddx are new, with these newer you wanna newer wine too... do not ask me why it is like that, but that is how it is from mine experience 🤣

[dungeon007]

@axeldavy
For windowed mode one could even use native imm32.dll override 🤣 Fullscreen and changing resolutions is the problem, that xrandr code in wine chaged quite a lot since wine 4.0, so i am not surprised something will be broken there.

[dungeon007]

And then there are this amdgpu bug long time regression involved that appear on nine only ... likely some HW got borked DC since let say kernel 5.2 🤣

[leipero]

@dungeon007 Just tested without amdgpu DDX driver (using modesettings driver), same issues, that would sugget that issue is indeed with WINE and gallium nine.

[dungeon007]

"however, I did found another game where ssimilar issue happens (NFS Hot Pursuit 2 using DX8toDX9), only on gallium nine".
I have that game and i did run it with d3d8to9, does that also starts in a non stretched way like rfactor too for you or something else?
Here it does not do that, but there are leftovers of previous window during resolution changes inside a game, say when your are going from game menu which is at (800x600) to something else for an actual gameplay, same way when you are exiting game to the menu again...
And if that is the bug, that bug started with a kernel that i mentioned, i am quite sure 🤣

[dungeon007]

Or maybe that transition from one to another resolutions are just more visible to the user... anyway after that messy transition (which is not so nice to watch 🤣), everything is fine again.

[dungeon007]

BTW i am testing this in openbox and i usually have SMFA (Scaling Mode Full Aspect) enabled via xrandr.
Well, that is not by default, as default is None, but i like to enable that. 🤣

[dungeon007]

So, maybe you can try that to force via xrandr too, instead of what rFactor is doing there 1920x1080 (>4:3 Wid... escreen or whatever, i am guessing) 🤣

[dungeon007]

That should work with amdgpu ddx and kernel with amdgpu.dc=1, so something like:
xrandr --output HDMI-A-0 --set "scaling mode" "Full aspect"
to turn it on and to turn it off:
xrandr --output HDMI-A-0 --set "scaling mode" "None"
Just check name of your output there with xrandr and put that output name there.

[dungeon007]

I mean that shouldnt do stretching of 4:3 resolutions on 16:9 screens, if that is what you want.

[leipero]

"however, I did found another game where ssimilar issue happens (NFS Hot Pursuit 2 using DX8toDX9), only on gallium nine".
I have that game and i did run it with d3d8to9, does that also starts in a non stretched way like rfactor too for you or something else?
Here it does not do that, but there are leftovers of previous window during resolution changes inside a game, say when your are going from game menu which is at (800x600) to something else for an actual gameplay, same way when you are exiting game to the menu again...
And if that is the bug, that bug started with a kernel that i mentioned, i am quite sure

I don't know, I did not test it at that resolution, I've tested only at 1080p (using WS fix, you can find it here on github). However, it's not the same, it basically "lifts up" the imaginary window in the full screen, resolution is the proper 1080p, bad wording on my side, but I'm 99% sure it's the same issue that does that.

I'm running scaling mode to full aspect always, this is really not an issue with DDX driver, since basically, in every single other scenario it works as it should, except with WINE and gallium nine combined.

[dungeon007]

Well, mention it if you are trying to use some third party widescreen fix, as these always trying to do soemthing else... i guess you mean this one?
https://github.com/xan1242/hp2wsfix

[dungeon007]

Not sure which one you are using there? One for XP, one even increases memory usage or whatever 🤣

[dungeon007]

Unsure in procedure too, i have to rename d3d8 to dinput and then i guess also to put d3d8to9's d3d8 along side it... and it have two cofig files, where i could enable or disable, but i could force d3d8 to native via wineoverrides anyway....
If you could, decribe me procedure you are using there so i could try to repro it.

[dungeon007]

And it seems it put saves into it save folder, even if i didnt checked that... either this is kind of broken or i am not following procedure correctly.
Do you use any game command switch like "-nofrustration"? 🤣

[dungeon007]

Seems it looks all fine here to me:
https://i.postimg.cc/4xy0zt84/menu.png
https://postimg.cc/QB2yn6NK
so no idea, does anyting looks wrong to you there?

[dungeon007]

But i took that one for XP, maybe another one would make some problems 🤣

[dungeon007]

Only videos seems to go off by default, if without -nofrustration 🤣

[dungeon007]

No idea how to reproduce this, do you replace d3dx9_43 and d3dcompiler_43 as native for d3d8to9 usage? There is a great possibility that something could go wrong with builtin wine ones in that regard.

[dungeon007]

At the end you can try on something other wm than Gnome i guess, maybe that is doing something else with windows, who knows 🤣

[leipero]

Seems it looks all fine here to me:
https://i.postimg.cc/4xy0zt84/menu.png
https://postimg.cc/QB2yn6NK
so no idea, does anyting looks wrong to you there?

Everything seems fine, except image quality that seems bad (another issue with nine in comparison to WINE D3D and DXVK). Videos going off is strange, but it does happen. I use 2.4 (latest) version of WS fix, and I did override d3dx9_43 and d3dcompiler_43 to native (otherwise image is not rendered properly), with wine 6.4.

Here it is, and again, only with gallium nine (not with WINE D3D or DXVK), as you can see, it's slightly tot he left and up:

[dungeon007]

Not sure how to measure quility of images there really... maybe i am blind in that regard 🤣
But i do notice that "lift up" how on your picture menu goes up somewhat, but on mine is more lower, is that an issue?
Could be that xrandr patch again as mine wine have that reverted.

[dungeon007]

I will recheck without revert later on... but anway maybe that is size of Gnome decoration that came in controling windows somehow 🤣

[dungeon007]

BTW, i took screenshot wit scrot and that defaults to 75% image quality... so there are more quialty in it for real 🤣

[leipero]

@dungeon007 You need to compare it with WINE D3D or DXVK for image quality (basically, image quaility at the distance, especially road - road lines for example), but that is off topic. I don't see that it goes up on your image, but it may be a little bit to the left, and yes, that is an issue, again, you need to compare it with WINE D3D or DXVK, regardless on your image is nowhere near how it is on the image I've posted (it's pretty obvious).

Also, can you please keep one compact post and edit it if needed (not multi posts one after another without someone responding), this way we are making it harder for anyone to track it, therefore making it less likely for someone to read = making it less likely to be resolved. Thank you.

[dungeon007]

So you mean about rendering quiality, if you are looking down the road... well it could be that filtering is different That does not mean that wined3d or dxvk do it right anyway.
Maybe to compare it versus Windows would be right 🤣

[dungeon007]

"Also, can you please keep one compact post and edit it if needed..."
No i cant, i am running on incompatible browser that GH seems does not like, so sorry i cant use all feautures there 🤣

[dungeon007]

But for sure i will take pictures with force scrot -q 100 next time, just for your pleasure 🤣

[dungeon007]

There you go, scrot force 100 quality and unpatched wine 6.4 🤣
https://i.postimg.cc/gJPWN9H4/menu.png
https://i.postimg.cc/dtR4Tbhw/game.png
And still it seems to me i cant reproduce your bug.

[dungeon007]

It is easier for you to try something else than Gnome, than i should try to install every single linux DE just in this gloruious attempt in trying to reproduce this isssue
Maybe try to disable wm decorations in winecfg or something like that... i am running out of ideas there really. 🤣

[dungeon007]

And here is your comparison of Xbox vs Playstation 2 vs GameCube 🤣

DXVK
https://i.postimg.cc/15rCn8tv/game-dxvk.png
NINE
https://i.postimg.cc/dtR4Tbhw/game.png
WINED3D
https://i.postimg.cc/htbBG4Wn/game-wined3d.png

Yes filtering seems far different on one on this one, but still we cannot expect that all 3 gaming consoles act the same everywhere 🤣

[dungeon007]

BTW this is done on AMD Athlon 5350, old lowpower potato APU 🤣

[dungeon007]

And no comment about perf there, but that seems is what i get on that scene 🤣

[axeldavy]

The road looks indeed bad. On the other hand it's hard to judge for the other items.

I know that last I checked, wine wasn't supporting the flag to autogenerate mipmaps, but they might have fixed that since. I don't know what DXVK does. Anyway having a trace of the scene (see wiki) would help find out why the road is incorrect.

[dungeon007]

I dont look that far in details when i am drive fast 🤣, seems near it is OKish, but far it is kind of filtered too much.
Will do a trace (if OP wont), just didnt checked yet on this one if vendor overrides do something there too like in Mafia 🤣

[dungeon007]

override_vendorid seems do nothing there...
And checked wined3d on wine 4.0 too, image is the same there, perf there about10% lower on that older one... if they fixed something they did it long ago or who knows maybe it was a bug somewhere in mesa gl 🤣

[dungeon007]

@axeldavy
Not sure if this trace of any use to you, for an rendering issue... throws these invalid unsupported format i think, but anyway 🤣
https://drive.google.com/file/d/15CS8_bq8urJMN6kdUmIcE7jb9Kzx5bsf/view?usp=sharing

[dungeon007]

I mean if is OK just say, BTW game support even -nomipmap switch. That looks bad but seems does not show this issue, so maybe you are interested in that one too? 🤣

[dungeon007]

"On the other hand it's hard to judge for the other items."
Why not? Oschowa said something useful up there:
"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."
So to me that is it, something happens in Gnome that seems makes apps dont scale correctly 🤣

[dungeon007]

So for this bug, we probably need some Gnome power user to investigate this 🤣