Holy Tenacious Tales of Zestiria, Batman!

I liked Bassmadrigal's idea and I've updated the SlackBuild.

1 members found this post helpful.

Hello again dugan
I have now read through all that I can find regarding what the wine-pba patches accomplish and it looks very interesting. Since I use nvidia's .run installer I checked in "/var/log/nvidia-installer.log" to try to determine what version of OpenGL libraries it installed. All it says is that it "is installing both new and classic versions" for 64 and 32 bit. However since my current driver is 390.25 it is likely safe to assume it is post OpenGL 3.15 since that was current in the nvidia driver almost four years ago. So I would like to try the wine-pba patches even though it is obvious that the author is playing a much newer version of WOW. I have not the deep skills of the author and all I can say is that I think he nails it that a "classic pipeline stall" commonly occurs and that the GPU is not been efficiently employed.

I am by no means displeased with my much older version WOW performance but there are a few annoying locations and situations where FPS drops under the cap I've set of 60fps (matching my refresh rate) which should be a walk in the park for a GTX 1070 Ti.

My question is would you recommend inserting the patches in the Slackbuild or applying them to the finished package? There is a mention of install order which is likely handled by the numbered naming convention in the pba patches but I am uncertain if an order includes waiting till all of the wine-staging patches are applied or if they should be invoked before those.

I haven't tried it, but the correct order must be to apply the wine-staging patches first.

So.... do I understand correctly that the 0001 thru 0005 wine-pb patches should be enabled at the end of list of enabled patches in your patchinstall.sh script?

Sorry, I just need to comment on this, as I think it can probably be made less ugly.

I assume you're on -current, with a kernel that's at least as up-to-date as -current's stock, and running WINE 3.3?

WINE 3.3 has vastly improved gamepad support, and it uses SDL2 to detect your gamepad and its control mappings. That means that if you just set up your gamepad for SDL2, then games running in WINE will detect it as an XInput-compliant Xbox 360 controller and work with it. I tested and confirmed that last night.

If you don't know how gamepad detection in SDL2 works (I have no idea if you do, okay?), there's an explanation (by Icculus) here:

https://youtu.be/MeMPCSqQ-34?t=32m

I like to use this tool to generate my SDL2 gamepad mappings. It's not exactly Slackware-optimized, but it does work:

http://generalarcade.com/gamepadtool/

There's an end-user-targeted guide here:

https://boilingsteam.com/making-thir...h-steam-games/

And a lot of examples here:

https://github.com/gabomdq/SDL_GameControllerDB/

The point is that you just set an SDL_GAMECONTROLLERCONFIG environment variable to match your gamepad, you launch the game in WINE, and it works with your gamepad.

I'll bet you anything that you don't (currently) need to use xboxdrv, which is really for older kernels that didn't have perfectly-working gamepad support.

Also, WINEARCH is only looked at when you're creating the WINE prefix. Once the prefix has been created (using winecfg or wineboot), WINEARCH is ignored. You can take it out of the script.

Actually no, I was using the wine-d3d9-nine 3.2 tree for that game, but hearing about that improvement in wine 3.3 sounds good! I was thinking wine would benefit from something like that, I will have to update wine and try again to see if it has improved. In this case xboxdrv is used to trick the game into thinking I have a xbox360 gamepad which I don't have.

I think it might be possible to use antimicro which is available at SBo to get the gamepad mappings. Or I might be able to copy them from a program like pcsx2 which already has them.

Lastly, I realize WINEARCH is not really needed in my scripts, but I find it valuable to aid me in remembering what arch the wine prefix is configured to use.

1 members found this post helpful.

Thanks! Had some problems with make -j, but that was easily fixed.

By the way, CSMT is enabled by default in vanilla 3.3. But in staging 3.3 there's still a checkbox that applies CSMT in winecfg. Does that need to be checked, or doesn't matter anymore?

I'm afraid this link is the best answer I can give you:

Why do we need wine-staging 3.3 when the CSMT is enabled by default in wine3.3.

1 members found this post helpful.

Ah, OK, that makes total sense. I was under the impression that the CSMT trees from staging and vanilla had merged.

Wine-staging version 3.6 has been released.

https://github.com/wine-staging/wine...eases/tag/v3.6

1 members found this post helpful.

I updated my SlackBuild yesterday.

I don't need this thread updated every time there's a new wine-staging release. I'll see the news on /r/linux_gaming. And if I'm not checking at the time... well, then I wouldn't see it here either. In that case, you can just do a VERSION bump.

Cool! And no "make -j," I see.

Is there a tutorial for using Dxvk and WINE? Seems like every version of WINE is different with respect to dxvk. (One needs to be using the beta Nvidia drivers, or is it driver-independent now?)

If you want to specify the number of jobs, just set MAKEFLAGS before running the script

DXVK is all /r/linux_gaming is talking about these days. But it sounds like you're already familiar with that.

I haven't tried DXVK myself.

One thing I did notice though: to get 32-bit Vulkan support on a multilib system, you need to run convertpkg-compat32 on Slackware's vulkan-sdk package and install it before building.