iXit / wine-nine-standalone

Build Gallium Nine support on top of an existing WINE installation
GNU Lesser General Public License v2.1
276 stars 23 forks source link

Implement scaling of rendered content to window/screen size #21

Closed Oschowa closed 3 years ago

Oschowa commented 5 years ago

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:

Screenshot from 2019-03-27 15-03-11

Screenshot from 2019-03-27 15-06-00

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

Oschowa commented 5 years ago

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 commented 5 years ago

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

leipero commented 5 years ago

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: 2019-10-08 12-19-07 2019-10-08 12-19-20

It makes mouse control inaccurate as well.

axeldavy commented 3 years ago

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

leipero commented 3 years ago

@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: 2021-03-17 01-24-53

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

"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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

leipero commented 3 years ago

"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 commented 3 years ago

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 commented 3 years ago

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

dungeon007 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

dungeon007 commented 3 years ago

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

dungeon007 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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: 2021-03-18 09-20-24

dungeon007 commented 3 years ago

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 commented 3 years ago

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

dungeon007 commented 3 years ago

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

leipero commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

"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 commented 3 years ago

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

dungeon007 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

dungeon007 commented 3 years ago

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

axeldavy commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

"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 commented 3 years ago

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