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

[dungeon007]

"cos DXVK doesnt" Actully DXVK just ignore WM behavior here, like with ATWMTCTW disabled... so nope, it just looks like it is working but that does not work too. 🤣

[dungeon007]

Probably good default for NINE is GDI and ATWMTCTW disabled, so that users does not see such issues by default 🤣

[leipero]

For me, it doesnt. TMNF going to window is broken if ATWMTCTW "Allow the window manager to control the windows" is enabled

Can't replicate, neither on WD3D, nine or DXVK, on both GS and LXDE. Both D3D and nine behave exactly the same (as expected), did not test DXVK extensively. All defalut, only GPU scaling is enabled (it shouldn't matter, but it could).

You are still not getting it, it's not about what works for you or others, if there's an issue, the goal is to resolve, instead of spamming, you should provide all the information about the issue you are facing now if you want to help, if don't, then remove yourself from the conversation.

[dungeon007]

It is not spamming, i would rather recommend better defaults to users, than default with more issues. That is what i am thinking about here. 🤣

[dungeon007]

"Can't replicate, neither on WD3D, nine or DXVK, on both GS and LXDE."
Well, i am runnin latest version of TMNF, not your switched down version below of TMUF 🤣

[dungeon007]

"Can't replicate, neither on WD3D, nine or DXVK, on both GS and LXDE."
Not sure if you are doing the same thing, cos you might understand it differently.
I start in fullscreen from a launcher at 1920x1080, but then once i am in a game i click on game panel top right to go to the window and all that with ATWMTCTW previosly enabled there is the issue 🤣

[dungeon007]

It could be done in different way, to start in window from a luancher. But this isnt from a launcher, this is from a game itself... TMNF version 2.11.26 🤣

[dungeon007]

"You are still not getting it, it's not about what works for you or others, if there's an issue, the goal is to resolve, instead of spamming, you should provide all the information about the issue you are facing now if you want to help, if don't, then remove yourself from the conversation."
Remove youself, what in the hell you are doing in this thread if you cant replicate issue with Dragon's Dogma? 🤣

[leipero]

It is not spamming, i would rather recommend better defaults to users, than default with more issues. That is what i am thinking about here.

THIS IS NOT A FORUM! This is a bug report with main goal to fix the issue, not to work around it, your behaviour is counter productive (especially spamming and misdirecting, not to mention that you've did post insulting things that would matter for people who give a weight for opinions of other people, by calling people dumb "indirectly" - this IMO is enough to deserve a report function being used).
This bug report is polluted with spam mainly thanks to the fact of your lack of understanding of what is going on, someone have to have a lot of nerves (and time) to go through all of that = rendering whole bug report useless for most people (if not resolved and closed).

In bug reports, there are few assumptions made that should always be the case:

1. Users who report bugs should have default configuration or mention any changes they made.
2. If someone can't replicate the issue, you are assuming that he done everything correctly, and that issue doesn't show on his part. From that, who should, can come up with some conclusions.
3. You should do all relevant tests and post results in one comprehensive post. If there are some workarounds already mentioned, there's no need to repeat it 100 times, they can be useful to narrow down the issue, so it's not wrong to mention them, but if issue is already identified, there's no need to repeat such things.

As for the issue you are facing with this fixed branch, as I said, I can't replicate it, hence I can't help, that should be enough (there are only two ways to change it from fullscreen to windowed, either by clicking or by using alt+enter, version of the game is not that relevant for this, since .26 have fixes mainly IP related, and few crash fixes that could be related to the texture/shading issue, but if it will make it any better, can't replicate on .26 either). If you really wanted to help, you would mention all conditions and provide screenshots and whatever is needed in one comprehensive post.

If it's any of your business, I've made a single post because I thought the issue I was facing back in 2019 is related to the issue Oschowa faced in MULTIPLE games, hence my response. It was not a priority issue for me at that time or now, the only reason is to help resolve it if I could.

[dungeon007]

"THIS IS NOT A FORUM! This is a bug report with main goal to fix the issue, not to work around it, your behaviour is counter productive (especially spamming and misdirecting, not to mention that you've did post insulting things that would matter for people who give a weight for opinions of other people, by calling people dumb "indirectly" - this IMO is enough to deserve a report function being used)."
If you feel ofended by anything, then please do that report function. 🤣
"This bug report is polluted with spam mainly thanks to the fact of your lack of understanding of what is going on, someone have to have a lot of nerves (and time) to go through all of that = rendering whole bug report useless for most people (if not resolved and closed)."
Bug threads could have less comments, bugs could have more comments... what is the difference?
"In bug reports, there are few assumptions made that should always be the case:

Users who report bugs should have default configuration or mention any changes they made.
If someone can't replicate the issue, you are assuming that he done everything correctly, and that issue doesn't show on his part. From that, who should, can come up with some conclusions.
You should do all relevant tests and post results in one comprehensive post. If there are some workarounds already mentioned, there's no need to repeat it 100 times, they can be useful to narrow down the issue, so it's not wrong to mention them, but if issue is already identified, there's no need to repeat such things."

I amight do that, if you say FOR ME once 🤣
"As for the issue you are facing with this fixed branch, as I said, I can't replicate it, hence I can't help, that should be enough (there are only two ways to change it from fullscreen to windowed, either by clicking or by using alt+enter, version of the game is not that relevant for this, since .26 have fixes mainly IP related, and few crash fixes that could be related to the texture/shading issue, but if it will make it any better, can't replicate on .26 either). If you really wanted to help, you would mention all conditions and provide screenshots and whatever is needed in one comprehensive post."
Here is the screenshot, quite similar if not the same as yours from before 🤣
https://i.postimg.cc/vHKBYwQ0/screenshot.png

[dungeon007]

Low textures, image shifted up, and on the side... full featured like the one from you from before.
But that isnt low textures, or anything like that that. It is just 640x480 window wrongly stretched to near FullHD if ATWMTCTW is enabled 🤣

[dungeon007]

Basically bug there is: if ATWMTCTW is enabled, NINE does not change to requested resolution. So instead of doing 640x480 window, when requested to go to window from a game, it does something wrongly - stretches window to near fullcreen 🤣

[dungeon007]

But there is more to it, because this does not happen even with stalone 0.7... if fulscreen is anything but not 1920x1080 🤣
Let say it like this, if i go to 1440x1080 fullscreen and then to window from a game, it works correctly. So for any fullscreen 4:3 resolutions, changing to window works correctly. And only prob is going from 1920x1080 to a window 🤣

[dungeon007]

Now with fixed branch it goes to right fullscreen resolution of 1920x1080, but going to window is still an issue if ATWMTCTW is enabled 🤣

[dungeon007]

All lesser 16:9 resolutions are not affected going to 640x480 so 4:3 resoltion windowed, only native 1920x1080 is affected.

[dungeon007]

Anyway, let me explain why i dont care about all this? That is because game is really 4:3 and interface is stretched anyway, if you try to play it on any else aspect ratio 🤣

[dungeon007]

So, should this be fixed? No, nope. i dont think so. If you really want to push it to that, then go to the workaround and that is it 🤣

[dungeon007]

Same goes to NFSHP2, does the road looks bad? Nope, it looks fine to me. It looks the same as on Windows by default.
But if you really want to make it look prettier, there you go to the variable and that is it 🤣

[axeldavy]

@leipero Thanks for the testing, glad the subissue is solved

@dungeon007 So to sum up the winecfg checkbox to allow the WM to control the window still gives issues (you see shifts) and apparently you have the same shifts with wined3d and not dxvk (but you have another problem with dxvk which makes you think the WM is not in control). Please refrain from giving your opinion here, a bug report should only contain information of test results. It's not helpful to have messages repeating the same information or giving your opinion or advising other users repeatidly with the same info. This would be more appropriate on a chat like the #d3d9 irc chan on freenode (gallium nine chat).

I talked with Oschowa privately and the issue he faces is an issue with Valve's fullscreen hack (@dungeon007 I see you coming. For exemple it's not helpful to comment this fact or advise the user to do differently). Due to some issues with fullscreen window decorations, there is a (1, 1) offset detected which forces a path that clamps the output and prevents Valve's fullscreen hack from working. The (1, 1) offset is a bug, and DXVK faced it at some point and solved it by filtering a window message. Wined3d doesn't seem to have this issue, and as our code for window messages comes from wined3d, I'll try to update our code with last wined3d changes hoping this helps. I can replicate the border issue as when I go windowed from fullscreen with the game I have a 1-pixel wide white border on each side.

[dungeon007]

That is it, i am done with this.

[dungeon007]

I mean to sum it up, good bye 🤣

[dungeon007]

This is what i get when i run it in fullscreen: https://i.postimg.cc/mk6p0H28/99.jpg

And to all GNOME extremists, i also on this day have one thing to say - Viva la RMS 🤣

[axeldavy]

Alright, the issue of this bug report should be fixed in
https://github.com/iXit/wine-nine-standalone/tree/more_fullscreen_changes

[dungeon007]

Looks fine to me. If it works for OP and Dragon's Dogma, you could close bug.
As always, If it does not work on new Gnome 40, he can open up another. 🤣

[leipero]

@axeldavy
Works fine as you already know probably. Trying to figure out what caused texture/shading issues (kinda dificult, lot's of mesa build errors for 19.0 against repo's llvm, I think it did work fine on that version but have to be sure, so bisecting is out of the question, will run VM and try that path since I don't want to mess up my working OS, so I can bisect there if all goes as planed).

@dungeon007
You have crossed the line, this is not the place for things you are posting. I've reported you for spam. Bye.

[dungeon007]

"@dungeon007
You have crossed the line, this is not the place for things you are posting. I've reported you for spam. Bye."
Viva la RMS, again 🤣