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 (Nvidia) / Unknown (AMD/Intel)
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)
-graphics-force-refresh <VALUE>
doesn't affect the behaviour at slightestKnown partial workaround (invalid for windowed mode)
Unknown, but probably caused by disabled/unavailable touch API in wine
-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)
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
IDirectSoundFXGargle
IDirectSoundFXEcho
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 "signal_spice" 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)
Unresolved, possibly an audio<->input sync issue of some kind, alternatively scheduling
Unkown, may be caused by bmsound-wine