VOGONS


First post, by nybble

User metadata
Rank Newbie
Rank
Newbie

I would like to bring this to the attention of the DOSBox Developers Forum. Originally I was running DOSBox within Microsoft Windows 2000 w/ Service Pack 4 with no problems. After upgrading my box to Windows XP Media Center I continued to experience no problems at all. After a time of running DOSBox I realized that the [, ], and \ keys weren't working correctly. I read the FAQ that I could and found that having a non-standard keyboard layout may cause the problem. I compiled a quick WIN32 app to query the system as to what keyboard layout I was using and it properly returned U.S. English. That quickly ruled out an improper keyboard layout. I shrugged it off as a Microsoft Update that somehow affected DOSBox and hoped this would be addressed in an update. After playing Star Trek Bridge Commander on the same machine, I noticed the exact same keyboard layout problem. As this program would not surface in applications like AIM, Internet Explorer, MS Word, or even an alternate operating system like Ubuntu Linux, I began to look into this problem in more detail.

As of this date, I have determined the cause of the problem. The Microsoft Media Center Remote Control that interfaces with my computer via USB is the cause of the layout malfunction. I had recently rebuilt my computer and inadvertently forgot to connect the remote control. After installing Windows XP Media Center Edition, all the drivers, and all the patched, I installed DOSBox, and noticed that it had been working properly. The night before, I reconnected my Media Center Remote and went to bed. The next day when I opened DOSBox I realized that the [, ], and \ keys were incorrectly mapped again. On a hunch I closed DOSBox, disconnected the remote, reopened DOSBox and interestingly enough the keys were properly mapped again. To ensure the problem was reproducible, I closed DOSBox, reconnected the remote, opened DOSBox, and the keys were again, mismapped.

There is an apparently incompatibility between the input API used by DOSBox and the Microsoft Media Center Remote Control. Please correct me if I am wrong, but I am willing to bet that DOSBox uses DirectInput, the input API of DirectX, as the primary input source from the keyboard. If this is the case that would explain why there could be a conflict between the remote and any application that uses DirectInput, such as Star Trek Bridge Commander.

If this is outside the scope of the developers of DOSBox the blame falls on Microsoft; and as such I believe it is our responsibility as developers to tell them they have a problem with the DirectInput API when it comes to interfacing with the Media Center Remote. If this is a problem addressable by the DOSBox developers, I would like to thank you for taking it upon yourselves to research into this bug. It is only a minor inconvenience to have to disconnect my remote every time I wish to use DOSBox, however, I feel it is an issue that needs to be addressed. I duly appreciate the effort put into this project and feel that everyone who uses it should give back to the community that developed it.

Following are the hardware specifications of the system affected by what I believe is a DirectInput glitch:

ABit FATAL1TY AN8-SLI Motherboard
AMD Athlon 64 x2 4400+
2GB PC3200 OCZ RAM - Dual Channel Configuration
BFG GeForce 7800GTX OC 256MB
Seagate Barracuda 160GB 7200RPM SATA HDD
Maxtor MaxLine Plus II 250GB 7200RPM SATA HDD
Lite-On 52x Max CD-ROM Drive
3.5" 1.44MB Floppy Disk Drive
Antec NeoHE 550W PSU

Thank you all again for the continued effort into this fantastic emulator.

Never eat shellfish during months other than those ending in the letter 'r'.

Reply 1 of 9, by bugs_bugger

User metadata
Rank Member
Rank
Member

Sorry, but I have to tell you that you are wrong with assumptation that DosBox uses DirectInput. DosBox uses SDL, the Simple Directmedia Layer. It is a very portable Library and you can compare its keyfeatures with those of DirectInput, DirectDraw and DirectSound. 3d is realized via OpenGL. Networking support is also available. So if your problem is caused by the API, you will have to contact the developers of SDL. Alternativly you can to to people like Gulikoza or Ykhwong here, they are skilled coders and have already made changes on DosBox to use DirectX for speed improvement.

Reply 2 of 9, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Well SDL might be using DirectInput.
although the way of keyinput seems to be related to the selected graphics mode.

Water flows down the stream
How to ask questions the smart way!

Reply 3 of 9, by wd

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Depending on the version of dosbox you are using, it uses the direct
input interface pretty surely.
In dosbox 0.65 you can try to set the usescancodes= entry in dosbox.conf
to false, and/or set the SDL_VIDEODRIVER to either directx or windib.

Reply 4 of 9, by nybble

User metadata
Rank Newbie
Rank
Newbie

Update: I set userscancodes to false in dosbox.conf however this had no effect on the keymapping error. SDL_VIDEODRIVER is not located in that file and as such I'm uncertain to it's location.

However, I downloaded the SDL Runtime v1.2.11 from the SDL Development site. After extracting SDL.dll from the archive, I replaced the existing SDL.dll in the DOSBox directory with the one from the SDL Development archive. This DID resolve the issue. Keymappings now work properly with the Media Center Remote connected to my PC.

I am concerned however with what impact this other SDL.dll file will have on the performance of DOSBox as I have had insufficient time to test it. Both SDL.dll files have the same creation date "Thursday, February 09, 2006, 11:10:00 AM", however the files differ in size by 145KB. The SDL.dll supplied with DOSBox is 397KB in size, while the one provided by SDL Development is 252KB.

Let's see where this goes, now that we're sure it's an SDL issue. 😀

Never eat shellfish during months other than those ending in the letter 'r'.

Reply 5 of 9, by wd

User metadata
Rank DOSBox Author
Rank
DOSBox Author

SSL 1.2.10+ uses the windib driver as standard (you can force this by
setting the environment variable like "SDL_VIDEODRIVER=windib").
So the bug is somewhere in the communication between SDL and the
directx driver.

Reply 6 of 9, by nybble

User metadata
Rank Newbie
Rank
Newbie

Applied and confirmed... While SDL_VIDEODRIVER is set to 'directx' the error exists. When switched to 'windib' the error disappears.

I shall be bringing this to the attention of the SDL developers.

For now this is a sufficient workaround I believe. I'll send an e-mail over to the DOSBox crew suggesting that they add this workaround to the FAQ where they describe problems with keyboard input.

Thanks a lot for your help guys... I'll be in touch should any more bugs develop.

Never eat shellfish during months other than those ending in the letter 'r'.

Reply 7 of 9, by wd

User metadata
Rank DOSBox Author
Rank
DOSBox Author

It would be better if the bug was resolved, rather than putting up
some workaround. Especially because the directx-interface will
be forced in the next version (as in the CVS currently), so just
copying a different sdl.dll won't work.

Reply 8 of 9, by nybble

User metadata
Rank Newbie
Rank
Newbie

Don't worry, I will be discussing this with the SDL developers. 😀 It's out of the hands on the DOSBox developers now.

Never eat shellfish during months other than those ending in the letter 'r'.

Reply 9 of 9, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

I am concerned however with what impact this other SDL.dll file will have on the performance of DOSBox as I have had insufficient time to test it.

I do *think* that with the dll that came with Dosbox you are able to set output=ddraw. With the one from the sdl site it may be that you get the message that ddraw is not possible and that it uses surface rendering.

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper