VOGONS


First post, by kruwi

User metadata
Rank Member
Rank
Member

So I think I have discovered a small but slightly annoying bug.

In Police Quest 2 the the keyboard is often annoyingly laggy. Sometimes you can type in characters and they will only show up after about 1-2 seconds. The mouse pointer also seems to be a little "nervous" at times, flickering a little bit. The game is still playable, but especially the keyboard behaviour is really annoying. Happens with both 0.74-3 and the newest clean svn builds which I normally prefer over the official 0.74-3 version. Using the standard config difn't change anything. Lowering the cycles to about 1000 or any other value didn't change anything, too.

My system: Windows 10 64 bit, 4 GB of RAM, Pentium N 5000 CPU.

It also happens in my dosbox-installed Ms DOS 6.22 environment using a hardfile image.

ScummVM runs the game without any annoying keyboard behaviour.

Visit the end of the internet: www.groskreutz.de

Reply 1 of 14, by kruwi

User metadata
Rank Member
Rank
Member

PCEM 15 (I have it set up to emulate a 486DX 33 running DOS 6.22) also manages to play the game without the weird keyboard behaviour - mentioned just for comparision 😀.

Visit the end of the internet: www.groskreutz.de

Reply 2 of 14, by kruwi

User metadata
Rank Member
Rank
Member

It doesn't happen with the "staging version" (dosbox staging) as of December 29th, 2019, using dosbox staging's standard configuration (output=texture, which is not available in standard svn).

Last edited by kruwi on 2020-01-09, 17:25. Edited 1 time in total.

Visit the end of the internet: www.groskreutz.de

Reply 3 of 14, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

DOSBox is fed input (keyb/mouse/joy) from the SDL library, so my guess is something is going wrong(*) in the unsupported-since-2013 instance of SDL used by DOSBox, versus the actively maintained instance of SDL used in dosbox-staging.

That's just a hunch, given your report and the fact that dosbox-staging hasn't changed the input handling code besides using the supported version of SDL.

Edit.. by "wrong", I mean any interaction(s) between the state of your Windows-10 installation (circa Jan-2020) versus those calls made by the circa 2013 SDL library resulting in the behaviour you mentioned.

Reply 4 of 14, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

Assumptions are nice, testing is better.

Use the following in the same directory as the existing 0.74-3

Use SDL 1.2.15 with exisiting DOSBox executable and test.
Use attached dosbox.exe which is latest SVN version with exisiting SDL.dll and test
Use attached dosbox.exe with SDL 1.2.15 and test

Attachments

DOSBox Compilation Guides
DosBox Feature Request Thread
PC Game Compatibility List
How To Ask Questions The Smart Way
Running DRM games offline

Reply 5 of 14, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

I assume that if it works with the staging version that has output=texture than it is the SDL2 version.
So that might mean it's an SDL issue (either SDL 1.2 vs SDL2 or SDL 1.2.13 vs 1.2.15)

BUT before you try anything else, try different outputs with lockstock o.74-3.
(Unless you did and I overlooked that)

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox

Reply 6 of 14, by kruwi

User metadata
Rank Member
Rank
Member

Ok, and the results are:

With SDL 1.2.15 there are absolutely no problems. Normal mouse and keyboard behaviour both in dosbox 0.74-3 and the latest SVN (which also is the dosbox.exe I normally use).

With the original SDL: the described problems occur, both with latest SVN version and in Dosbox 0.74-3. Laggy keyboard, "nervous" mouse.

EDIT: output=surface, that is

Visit the end of the internet: www.groskreutz.de

Reply 7 of 14, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

DosFreak, what differs between your SDL 1.2.15 versus whatever version is packaged with the DOSBox release?

Just curious.. I've see this approach recommend as a fix many times now, and often it does fix the issue. Are there cases where the opposite is true: your SDL version causes issues and the packaged DOSBox SDL solves it? (if not, then ideally your dll could be the new packaged version).

Reply 8 of 14, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Kruwi: could you try the lock stock one with different outputs? Surface is in some instances prone to problems (in others it works better 🤷‍♂️)

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox

Reply 9 of 14, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

The version I attached is the official SDL 1.2.15 (not post 1.2.15 but before SDL2).
DOSBox uses SDL 1.2.13 due to issue with 1.2.14+. I believe there were graphics issues (I haven't seen these) and SDL 1.2.14 broke directinput with 9x (not an issue if dinput not used). DOSBox includes a diff to patch SDL 1.2.13 related to a graphics issue.

The change to SDL 1.2.14 and 1.2.15 that broke directinput on 9x occurred IIRC because an ioquake3 dev submitted the patch but from what I've seen many didn't like it so alot of people stuck with 1.2.13 or decided not to use directinput with 1.2.14 and above. I have a patch I worked on with someone else on the forum (name escapes me right now) for SDL 1.2.15 for 9x to use directinput but if you don't use dinput then you don't need it.

To package SDL 1.2.15 with DOSBox without possibly breaking DOSBox on early operating systems that the official version of DOSBox supports would require testing 95,98,NT4,XP,Vista,7,8,8.1,10 to verify.
Possibly would be fine without testing on Vista+ since the only recent bug within the past year or two was when MS broke the mouse with SDL with one of their updates but then later fixed it.

If not worried about >XP then SDL 1.2.15 might be fine without testing. Would still be nice to test on Vista+ since we have a ton of hardware here vogons would likely be the best place to do it.

DOSBox Compilation Guides
DosBox Feature Request Thread
PC Game Compatibility List
How To Ask Questions The Smart Way
Running DRM games offline

Reply 11 of 14, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

There are alot of games out there that are compiled against SDL 1.2 so hopefully that continues to be the case. I doubt anyone cares though since they aren't fornite.

DOSBox Compilation Guides
DosBox Feature Request Thread
PC Game Compatibility List
How To Ask Questions The Smart Way
Running DRM games offline

Reply 13 of 14, by kruwi

User metadata
Rank Member
Rank
Member

@Dominus:

I haven't had the time yet, but I will test different output options with the "old" version of SDL over the weekend... .

Visit the end of the internet: www.groskreutz.de

Reply 14 of 14, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

Changing SDL versions isn't as simple as the internets want you to believe. So maybe. Issues like the one you posted help. The official version of DOSBox will use SDL2....eventually. So use a build that uses that for now or use SDL 1.2.15 with the official version of DOSBox.

DOSBox Compilation Guides
DosBox Feature Request Thread
PC Game Compatibility List
How To Ask Questions The Smart Way
Running DRM games offline