- Sep 12, 2023
- 14
- 15
I succesfully ported my rpgm mv games to linux by updating nw.js per the guides posted here. Theres a minor issue where it creates a .pki folder in $HOME. Any way i can avoid this and let it use ~/.local/share/pki?
What if you just create a symlink pointing to the other directory? Something like:Any way i can avoid this and let it use ~/.local/share/pki?
cd $HOME
rm -r .pki/
ln -s .local/share/pki/ .pki
If you launch Wine from a terminal, what does the error say when the game crashes?Anyone has an idea why?
winegstreamer
isn't listed in winecfg's library list. Running the game without disabling winegstreamer, means running the game but with delayed sound effects (in the menu I can move around, but the sound effects don't all sound the same and are delayed and the terminal is constantly spitting out messages about dropped bytes in quartz:DSoundRender_SendSampleData
and data underruns in quartz:DSoundRender_UpdatePositions
. Passing WINEDLLOVERRIDES="winegstreamer="
runs the game but without any sound effects. Installing quartz through winetricks as someone talked about on here has the consequence of freezing the game for several seconds whenever a sound effect is to be played and never actually playing the sound effect.Hm, it seems to work okay for me using the instructions in the OP. I lack sound effects in the dialogues (should they exist) but they are fine for interactables (doors, etc) and the x menu, certainly no delay. And the endless music plays. (I'm using vanilla wine 8.20)Are the RPG Maker instructions still up to date?winegstreamer
isn't listed in winecfg's library list. Running the game without disabling winegstreamer, means running the game but with delayed sound effects (in the menu I can move around, but the sound effects don't all sound the same and are delayed and the terminal is constantly spitting out messages about dropped bytes inquartz:DSoundRender_SendSampleData
and data underruns inquartz:DSoundRender_UpdatePositions
. PassingWINEDLLOVERRIDES="winegstreamer="
runs the game but without any sound effects. Installing quartz through winetricks as someone talked about on here has the consequence of freezing the game for several seconds whenever a sound effect is to be played and never actually playing the sound effect.
This is with wine-8.17 and Henteria Chronicles: Chapter 1 main menu
Hey there. Do you have any joystick devices in your system? For example, some a4tech hardware provide such a device. Here is an example of my udev rule to deal with that (commented one was working for years before some update, I had to change it to be more specific):Hello! I've recently changed to a nvme and when I tried to copy the .wine prefix I made, the dll kernel didn't work or so it said. So I think it's better to create a new one on this new install, after installing a few things rpgmaker games ran fine, but now I'm having problems with unity games. the problem is that the mouse keeps spinning when I try to move it, but that only happens when I change winecfg to play using a virtual desktop, and not on full screen. Any ideas?
$ cat /etc/udev/rules.d/83-remove-a4tech-joystick.rules
SUBSYSTEMS=="usb", ATTRS{idVendor}=="09da", ATTRS{idProduct}=="77c8", RUN:="/bin/sh -c '/bin/rm -f $env{DEVNAME}; for i in $env{DEVLINKS}; do /bin/rm -f $i; done'"
#SUBSYSTEMS=="usb", ENV{ID_VENDOR_ENC}=="A4Tech", ENV{ID_INPUT_JOYSTICK}=="1", RUN:="/bin/sh -c '/bin/rm -f $env{DEVNAME}; for i in $env{DEVLINKS}; do /bin/rm -f $i; done'"
$ cat /etc/udev/rules.d/90-event.rules
KERNEL=="js*", SUBSYSTEMS=="input", MODE="660", GROUP="games"
KERNEL=="event*", SUBSYSTEMS=="input", MODE="660", GROUP="games"
#Xbox 360 Wireless Receiver
#Microsoft X-Box 360 pad
KERNEL=="js*", SUBSYSTEMS=="input", ATTRS{name}=="Microsoft X-Box 360 pad", ATTRS{properties}=="0", SYMLINK:="input/jsx1"
#KERNEL=="uinput", SUBSYSTEM=="misc", MODE="0660", GROUP="games"
export SDL_JOYSTICK_DEVICE=/dev/input/jsx1
, the usual evdev route doesn't work and evdev probably not even shipped with modern systems (it's libinput nowadays), so wine can have some problems with gamepads due to that (for example, for me, rumble was broken in some games, but working with joy.cpl). Not to mention a long-standing issue where games cannot detect your type of gamepad (wine problem). Likely won't be fixed ever, but then again, they've started fixing midi, so rpgmaker games are probably playable without the need to manually convert midi to ogg now (winetricks gmdls approach was fine but it made every other game broken).No I didn't have a joystick connected at the time, however just like your system, it was detecting something else as such, in my case the asrock led controller:Hey there. Do you have any joystick devices in your system? For example, some a4tech hardware provide such a device. Here is an example of my udev rule to deal with that (commented one was working for years before some update, I had to change it to be more specific):
If you're interested here is the rule for my xboxdrv device, I had some problems with my actual gamepad too (and it changed its name recently):Bash:$ cat /etc/udev/rules.d/83-remove-a4tech-joystick.rules SUBSYSTEMS=="usb", ATTRS{idVendor}=="09da", ATTRS{idProduct}=="77c8", RUN:="/bin/sh -c '/bin/rm -f $env{DEVNAME}; for i in $env{DEVLINKS}; do /bin/rm -f $i; done'" #SUBSYSTEMS=="usb", ENV{ID_VENDOR_ENC}=="A4Tech", ENV{ID_INPUT_JOYSTICK}=="1", RUN:="/bin/sh -c '/bin/rm -f $env{DEVNAME}; for i in $env{DEVLINKS}; do /bin/rm -f $i; done'"
For it to work properly I have to modprobe joydev module (uinput module is loaded by xboxdrv)Bash:$ cat /etc/udev/rules.d/90-event.rules KERNEL=="js*", SUBSYSTEMS=="input", MODE="660", GROUP="games" KERNEL=="event*", SUBSYSTEMS=="input", MODE="660", GROUP="games" #Xbox 360 Wireless Receiver #Microsoft X-Box 360 pad KERNEL=="js*", SUBSYSTEMS=="input", ATTRS{name}=="Microsoft X-Box 360 pad", ATTRS{properties}=="0", SYMLINK:="input/jsx1" #KERNEL=="uinput", SUBSYSTEM=="misc", MODE="0660", GROUP="games"
Still, I had some difficulties with Unity games not being able to detect my gamepad, it was only detected properly in fullscreen mode (fake fullscreen iirc).
Oh, there is alsoexport SDL_JOYSTICK_DEVICE=/dev/input/jsx1
, the usual evdev route doesn't work and evdev probably not even shipped with modern systems (it's libinput nowadays), so wine can have some problems with gamepads due to that (for example, for me, rumble was broken in some games, but working with joy.cpl). Not to mention a long-standing issue where games cannot detect your type of gamepad (wine problem). Likely won't be fixed ever, but then again, they've started fixing midi, so rpgmaker games are probably playable without the need to manually convert midi to ogg now (winetricks gmdls approach was fine but it made every other game broken).
$ cat /etc/udev/rules.d/01-asrock-LED-controller.rules
SUBSYSTEM=="usb", ATTRS{idVendor}=="26ce", ATTRS{idProduct}=="01a2", ATTR{authorized}="0"
If you have something related to alt-tabbing, you might need to add a registry key withto alt + tab and return
wine-staging reg add 'HKCU\Software\Wine\X11 Driver' /v UseTakeFocus /t REG_SZ /d no
and without that Unity games were constantly getting stuck after focus loss. I think they might've changed some behavior since then, but there was no proper fix yet at the time. Do you see any other devices in wine-staging control joy.cpl
(event ones are usually separate)?None, not in controllers, Dinput or XinputDo you see any other devices inwine-staging control joy.cpl
(event ones are usually separate)?
wine-staging reg add 'HKCU\Software\Wine\X11 Driver' /v UseTakeFocus /t REG_SZ /d no [ICODE], although I'm not using the staging version. should I change to that actually?
I mean, you probably should. If your distro provides a wine-proton package (like the actual one and not the user maintained or prebuilt because these will probably be dependent on unavailable system libs), also get that, as it has a much better game compatibility overall. In my opinion, it's an absolute must. Some rare cases (very rare) can be better with the wine-staging package still, I don't think I ever found anything where wine-vanilla was preferable. But you also supposed to manually install dxvk and don't forget to keep both prefixes separate. Don't pollute your prefixes with winetricks/protontricks much since doing so drops the chances that games will work properly.should I change to that actually?
I'll try that then. Also, is there a command that I can add to a .sh file that forces the game to NOT use the virtual desktop? so that in cases such as oedo trigger it goes full screen and at least the mouse will work, even if alt tabbing results in a crash, Allowing other games to still work with alt tabbingI mean, you probably should. If your distro provides a wine-proton package (like the actual one and not the user maintained or prebuilt because these will probably be dependent on unavailable system libs), also get that, as it has a much better game compatibility overall. In my opinion, it's an absolute must. Some rare cases (very rare) can be better with the wine-staging package still, I don't think I ever found anything where wine-vanilla was preferable. But you also supposed to manually install dxvk and don't forget to keep both prefixes separate. Don't pollute your prefixes with winetricks/protontricks much since doing so drops the chances that games will work properly.
Other than that, it might be something related to Wayland and/or WM (I've seen some strange behavior).
I don't think there is an env var for that, but you can disable it with regedit or winetricks (i.e.I'll try that then. Also, is there a command that I can add to a .sh file that forces the game to NOT use the virtual desktop? so that in cases such as oedo trigger it goes full screen and at least the mouse will work, even if alt tabbing results in a crash, Allowing other games to still work with alt tabbing
winetricks vd=off
). Pretty sure wine-proton is patched in such a way that vd is not needed anymore (like ever). Mouse issue might get fixed too. By the way, sometimes you have to disable dxvk, so WINEDLLOVERRIDES="dxgi=b;d3d11=b;d3d10core=b;d3d9=b"
can be used, meaning you don't have keep a separate prefix without dxvk. Don't forget to manually copy/link real windows fonts if you use wine (into ${WINEPREFIX}/drive_c/windows/Fonts/ since your fonts from other locations won't be used and you want proper fonts for many games).So it's worth a shot to change to wine-proton from wine-staging? Also proton comes from steam, right? Having steam installed won't do some shenanigans as to detect the game running and associate to steam profile right? I remember something like this happening when I was learning to run some games here on windowsI don't think there is an env var for that, but you can disable it with regedit or winetricks (i.e.winetricks vd=off
). Pretty sure wine-proton is patched in such a way that vd is not needed anymore (like ever). Mouse issue might get fixed too. By the way, sometimes you have to disable dxvk, soWINEDLLOVERRIDES="dxgi=b;d3d11=b;d3d10core=b;d3d9=b"
can be used, meaning you don't have keep a separate prefix without dxvk. Don't forget to manually copy/link real windows fonts if you use wine (into ${WINEPREFIX}/drive_c/windows/Fonts/ since your fonts from other locations won't be used and you want proper fonts for many games).
Yes, absolutely.So it's worth a shot to change to wine-proton from wine-staging?
I was using binary proton-ge-custom which is supposedly more or less the same as the actual thing and it was working without Steam runtime. Now I build valve-proton myself so it properly depends on my system libs (such as gstreamer and ffmpeg). The only difference from the usual wine I see is that user name is "steamuser". Oh and there is also protontricks tool (which I never used before).Also proton comes from steam, right? Having steam installed won't do some shenanigans as to detect the game running and associate to steam profile right? I remember something like this happening when I was learning to run some games here on windows
gloriouseggroll have a wine with fixes and features from proton (So it's worth a shot to change to wine-proton from wine-staging? Also proton comes from steam, right? Having steam installed won't do some shenanigans as to detect the game running and associate to steam profile right? I remember something like this happening when I was learning to run some games here on windows