If you know a possible solution, tested with different setup or found another issue you can report on it through an issue tracker
You may want to checkout Game Support and /Devel/<SPECIFIC_GAME> if your issue doesn't seem to be listed here
Resolved, but requires different workarounds depening of combinations of Nvidia/AMD/Intel and X11/Wayland
Multi-monitor setup with varying refresh rates (AMD/Intel behaviour untested)
Defining __GL_SYNC_DISPLAY_DEVICE=<DEVICE_NAME> environment variable, where <DEVICE_NAME> is a port name matching monitor used for game in xrandr -q output, this switches default vsync behaviour (which konami uses) to take monitor refresh rate from specified monitor instead of one with the lowest refresh rate, this requires specified monitor set up exactly to targeted refresh rate (which can be done temporarily with xrandr as well).
Alternatively gamescope could work as well in case of setups that support it.
-graphics-force-refresh <VALUE> doesn't affect the behaviour at slightestKnown partial workaround, currently tracked by #10
This is usually caused by game main window not being on primary display, this has been documentated by upstream #471
-touchemuforce as spice launch argumentResolved
Multi-monitor setups
Add spice argument -graphics-force-single-adapter, may want to combine this with -monitor <ID> for more complicated setups
Resolved (linux specific)
Known cause (out-of-scope)
Using unsupported DLL versions
Known cause (mostly out-of-scope)
DXVK introduces additional CreateDeviceEx() caveats compared to Windows, that may be fixed in the future (upstream)
Prefer using window mode and manually fullscreening instead (through window manager).
If you really need to use fullscreen try enabling `video.d3d9_fallback` which provides implementation more in-line with Windows - see caveats. Not recommended.
Resolved
May happen when you directly migrate your spicetools.xml config file between machines/versions, most likely bug in config migration between spice versions
<PREFIX>/drive_c/users/steamuser/AppData/Roaming/spicetools.xml and remove at least <buttons>..</buttons> bracket under specific <game name=""></game> title issue happens for<game name=""></game> bracket and reset all settings for specific game (including lights, card config etc.) to be on safe side, as this issue happens due to key duplicates in config and there may be more old config residueUnresolved, known possible fix, unknown implementation ETA
IDirectSoundFXWavesReverb IDirectSoundFXDistortion IDirectSoundFXChorus IDirectSoundFXFlanger IDirectSoundFXGargleIDirectSoundFXEcho seems to not do anythingUnresolved, possibly fixable through some library overrides
Known and intentional, alternative endpoint available
This is caused by bmsound_wine's "notif_spice" profile endpoint
You can use alternative audio endpoint by defining "loopback_signal" profile through config
This endpoint will become the default once this refactor is completed
Since winelib had issues with calling back to wine's address space from unix thread, "notif_callback" endpoint profile (more optimal for use with spice) cannot be used
To keep latency penalty at the lowest, alternating busy lock between threads was introduced as a temporary solution
CPU scheduling on most kernels should handle this well enough for end-user to not notice any additional stutters
That being said, this may cause stutters on low-end systems and higher battery usage for mobile devices
Known cause (out-of-scope)
If you can, ask maintainer of your hook to properly fetch dll's base address from inside hook in question, alternatively if source code of the hook is available you can create issue on this tracker and patched hook should be provided, below is usually all that's needed to make hook work consistently
// wrong (right most of the time)
static const long VA_BASE = 0x180000000
// correct (always right)
const long VA_BASE = (long)GetModuleHandle("game.dll")
As this is usually caused by author's wrong presumption that virtual address of the game's dll is guaranteed at runtime (often 0x180000000), this is not really something that can be reliably worked around from here
While wine makes sure to map libraries to their preferred base addresses where possible, in cases with multiple libraries requesting the same VA, next libraries with the same base address will be reallocated
This is the case for example with bm2dx.dll and avs2-core.dll, which both target the same address (with avs2-core.dll loading first, while author probably intended for bm2dx.dll to map there instead)
Resolved (linux specific)
gstautoconvert side.s3p for storage, use wma codec instead of wav (used with previous .2dx sound assets), only such assets are affectedResolved through workaround available in spicetools release here, see spicetools#1 bmsound_wine#6 for more details
Only workarounds available
This is usually caused by wma audio playback in combination of specific versions of Wine/Proton-GE
Resolved through enabling s3p=>2dx transcoder, currently only supported for IIDX. Also does not happen with proton-ge 8.32.