DOSBox: Games stutter and audio crackles while moving the mouse
-
I nailed the issue down to a combination of these two values in dosbox.cfg:
[sdl] vsync=true output=texture
When switching to output=surface or disabling vsync, the issue is gone. Unfortunately, disabling vsync seems to decreases performance in other situations. Observed in the intro video from System Shock f.e., with vsync=true the video plays much smoother.
-
I had the same issue. I didn’t have any problem with 6.0.
-
@Cap in ExoDOSConverter you can use expert mode to enforce values for output and some other other parameters, maybe you can try that and enforce output to surface (pay attention to the other enforced values though, maybe generate a game by defaulft first and copy the default values to use)
afaik you'll be the first to use the expert mode, so don't hesitate to enter an issue on the github if if there are bugs
-
@AgedLove Good idea! I played around with different settings (most of the time editing the config file directly over SSH) for vsync in combination with different setups for output and renderer. So far, I could not find a combination that has both (smooth videos and no crackles when mouse is moved). I think I'll stick with vsync turned off, as many games are unplayable otherwise because of the mouse issue.
This is also recommended in the Wiki (when using the pastebin link; the provided default config in /recalbox/share/system/configs/dosbox has vsync set to true instead).
-
@Cap yes vsync is very costly anyway, in the past it was not even really usable on pi3
-
I did some more tests with vsync=false and found another issue. With this setting, some games run smooth in the first few seconds, but then performance drops massively. Can be seen in Prince of Persia: When starting the game and skipping the title screen quickly, all animations look smooth (character, torches in the background), but then the game drops down to maybe 10-15 fps.
I remember a similar issue with ScummVM in the 7.0 release: https://forum.recalbox.com/topic/21886/scummvm-pi-4-laggy-animations
It looks exactly the same when playing Prince with vsync=false and the fix for ScummVM was enabling SDL vsync in the Python config generator package if I remember correctly. Maybe the issues are related somehow?
-
@Cap Have you tried that?
"See if it still happens if you disable the joystick emulation, set joysticktype=none in the [joystick] section of your DOSBox configuration file. " (https://www.dosbox.com/DOSBoxManual.html#CONTROL) -
@Zing said in DOSBox: Games stutter and audio crackles while moving the mouse:
Have you tried that?
Sorry for responding late! I tried it out today. Unfortunately it did not solve the issue. I made some videos for comparison with different settings for vsync and the joystick (apologies for the flickering and ghosting - I'm still in love with my old plasma TV ).
Video 1 - vsync=true / joystick=auto (game runs fine, but crackles and stutters in other games when moving the mouse):
https://drive.google.com/file/d/1pbFlCd8BjJwvoESBtKRqwarnzCUkgAF1
Video 2 - vsync=false / joystick=auto (game runs fine in the first few seconds, but after that drops down to 10-15 fps):
https://drive.google.com/file/d/1cSQQaYCfmoingki7lGnav24mx0whqf_K
Video 3 - vsync=false / joystick=none (shows the same issue as in video 2):
https://drive.google.com/file/d/1hM-MgBu0MlRGfVypZ-icdwuYrDLo_4z7
As a side note, when setting joystick=none, the virtual keyboard in DOSBox does not work anymore, or to be precise: it cannot be operated with the joystick anymore (works fine when using a USB mouse).
I also noticed that even with vsync=true the game shows some tearing effects. Below is one frame of video 1 (the half-way transparent green and magenta area is caused by my TV):
-
Hi,
There was another thread Id posted on re poor Dosbox and it's poor performance on the Pi4 - this may help?https://forum.recalbox.com/topic/21561/recalbox-7-0-dosbox-slow?_=1607765677783
My post was "Dosbox on a Pi4, at the moment, will never perform better than on a Pi3 it seems. Others are also finding the exact same issue as yourself [ what the postwr had mentioned in the above thread ], and I found this :
"it's to do with the framebuffer video driver included in the sdl1 library used by dosbox. The PI4 has a different kind of driver (it's basically emulated on top of the DRM/KMS primary video plane) which doesn't support resolution changing, as in the previous PI models.
For the Pi3, the scaling might have worked with 2 methods - either the fbcon SDL1 driver did the scaling to a resolution supported by the framebuffer, or the scaling was done by using the SDL1 dispmanx driver (PI specific).
The former is not supported anymore on the Pi4 - the latter works, but it's not 100% behaving the same as on a Pi3."
Hope that helps.
-
don't know were Recalbox is regarding that, but the move from SDL1 to SDL2 broke performances for most Dosbox cores too