I never had it to be honest. I don't know what could be happing. (either input from your os to dosbox or from dosbox to application).

The only thing I can think of is that the mouse buffer overflows. but codewise that isn't possible

A very curios problem I had with my wireless mice was that the USB hub was interfeering with the connection when I was downloading something (took me ages to find the culprit of this 😀).
Maybe you have an usb hub there as well and try to disconnect it and see if the behaviour still exists. I know, a shot in the dark, but it might help...

Sephiroth wrote:

I do not know how to reproduce this issue other than to play a game and experience it if it decides to happen. It happens in Duke Nukem 3D, Blood, Shadow Warrior, Rise of The Triad, Doom series, Heretic, Hexen, Strife, Wolfenstein 3D, Railroad Tycoon, and just about everything else as well.

Is a common factor in each of the DOS games you mentioned above just possibly the MILES sound system? This behavior has been noted in SYSTEM SHOCK and SYNDICATE WARS in the past, both of which use some release of the DOS Miles Sound System API. The MILES API includes a custom Int 08h routine has a bug which might lead to this behavior...

Just curious,

dvwjr

Uh, these are DOS games that were out prior to Miles appearing on the scene, unless I am mistaken. Besides, DOSBox doesn't support the Miles sound systems unless it is a hidden feature. I only enable SB emulation anyway.

I don't use any hubs as I find them utterly useless addons. This is especially true on a system with eight USB ports and three 1394 ports. So I doubt that this is related to an extra hub.

Finally, this is NOT a "common problem" with said games. I own the systems built to play these games, and they NEVER do this on them, only in DOSBox, and only on occasion. If it happened in the original games I would not have posted this thread, as it would clearly have been a game problem, not a DOSBox problem.

QBix, this doesn't happen in any other game or application on my system, so I doubt it's my hardware, and it also happens on the various hardware types I mentioned above. Would a Fraps help, along with a screenshot of the DOSBox console window?

Sephiroth wrote:

Uh, these are DOS games that were out prior to Miles appearing on the scene, unless I am mistaken. Besides, DOSBox doesn't support the Miles sound systems unless it is a hidden feature. I only enable SB emulation anyway.

I believe that you are mistaken. The John Miles Sound System DOS API has been around since 1991, fairly early in the DOS sound card era, considering that PC-DOS games using sound (other than the PC speaker) based on Adlib, Creative or Roland sound cards/modules really got started in 1988. There have been approximately 1800+ DOS games which used the Miles 3rd party PC-DOS Sound card API since the early 1990s. There were other PC-DOS sound card libraries by other companies, however Miles was the most successful. The current owner, RAD Game Tools purchased the Miles software from John Miles in 1995 and has since expanded out of the DOS game sound world to Windows and many other platforms and consoles. The game 7th Guest by Trilobyte in 1993 was one of the first huge DOS games to use the MILES PC-DOS sound API.

There is no need for Dosbox to support the Miles Sound System, since the Miles Sound System is an API (not a sound-card) and uses individually developed drivers (those pesky AIL2 *.ADV and AIL3 *.DIG, *.MDI files) to support the ISA sound-cards of the day. As long as there was a Miles DOS driver for the ISA sound-card, the game would support the sound-card. So in Dosbox, when you select the SoundBlaster you wish Dosbox to emulate, one still has to select the proper Miles SoundBlaster sound driver if said game uses the Miles sound-card API.

All that being said, the wide-spread use of the MILES API and linkable code did lead to many DOS games having the same occasional error as you described. The MILES code involved the use of its own Int 08h timer routine (IRQ 0 handler) to support the MILES custom timers. However, an improperly placed STI/PIC-ack pairing would cause problems when the MILES Int_08h would fall-thru to the original Int_08h handler, which then performed its own STI/PIC-ack before an IRET. This in combination with the defective Dos4gw mouse-callback code could cause mouse and keyboard 'sticky-ness'. So I would not place the blame on the Dosbox emulation, I believe that it is a DOS application problem.

Just my 2 cents,

dvwjr

I'd agree, except for the fact that this has never happened in real DOS on any of my machines. Again, if this happened on my games when playing on the real systems, I would have had no reason to post this thread here. If I disable sound and music, some of these old games run right in XP and do not do this even in XP. However, I do experience this behavior in DOSBox and ONLY in DOSBox, which is why I made the post. On 98SE whether within Windows or rebooted to DOS this behavior just does NOT occur. Several of those systems I use have the older version of the IntelliMouse, but none have a Diamondback, although one does have the old Boomslang that started Razer.

Still, only happens in DOSBox. Until I have it occur on a real system, I cannot believe that it is the game. Not only that, but I wasted a LOT of my youth playing these games on those real systems and never had this issue. We're talking ten good years of gaming and not once can I remember this happening, so at this point I am 100% positive it isn't a game problem.

try joysticktype=none

Besides, DOSBox doesn't support the Miles sound systems unless it is a hidden feature. I only enable SB emulation anyway.

Muahahahaha!! (Sorry, couldn't resist this one from Mr. Know-It-All)

I don't own Razer hardware, but once had a mouse from a friend, in order to test it. He tried the mouse on various systems, and it had a very similar problem on all of these systems. At first, the mouse was running fine on my PC, but all of a sudden it seemed to "reset" itself, the mouse cursor went out of control. A short time afterwards, the mouse would run OK again, until the next "blackout". The solution at that time was to swap the mouse with a new one - same model, but more recent "build". After that, it would work allright. We never found out what the actual problem was, but the fact that the new mouse worked perfectly hints towards a hardware/firmware (yes, the mice have firmwares!) bug.

EDIT: oh, just read that this might be a DOSBox-only problem. I'd try a "standard" mouse, though, just to see if it makes a difference. Another thing to try would be to play with the "resolution" parameter in dosbox.conf. And yet another thing to try is to set the "priority" entry in dosbox.conf to "normal,normal". One of my system has input troubles (keyboard, mouse, joystick) when that setting is at the default of "higher,normal".

ANOTHER EDIT:

Razer Diamondback 3G (infrared, not optical)

Infrared is optical, too. Merriam-Webster says: "of, relating to, or utilizing light especially instead of other forms of energy".

Oh and this happens in older strategy games and such as well, only instead of spinning, the mouse cursor will warp to one side or corner of the screen and seem stuck there for a moment or two.

I have the exact same issue. Did you ever find a solution? Began happening to me when I upgraded my Ubuntu Linux box from Feisty to Hardy. Same hardware and configuration - I'm not sure if it's the x-server in the newer version of Ubuntu Linux or if it's a change in Dosbox version 0.72 (I think the version was 0.65 on the older system). Anyway, I get this behaviour for all games that use a mouse. Sometimes if I move the mouse REALLY slowly, a game will be just barely playable; but it will often randomly move to a side or corner and get stuck,

klytu wrote:

Oh and this happens in older strategy games and such as well, only instead of spinning, the mouse cursor will warp to one side or corner of the screen and seem stuck there for a moment or two.

I have the exact same issue. Did you ever find a solution? Began happening to me when I upgraded my Ubuntu Linux box from Feisty to Hardy. Same hardware and configuration - I'm not sure if it's the x-server in the newer version of Ubuntu Linux or if it's a change in Dosbox version 0.72 (I think the version was 0.65 on the older system). Anyway, I get this behaviour for all games that use a mouse. Sometimes if I move the mouse REALLY slowly, a game will be just barely playable; but it will often randomly move to a side or corner and get stuck,

The mouse problem disappears when I change my the mouse driver in my /etc/X11/xorg.conf from evdev to a standard mouse driver. The thing is there were no mouse issues with the older version of evdev and the older version of DosBox that I used to run on this same machine.

I'll do some poking around and try to figure out the right information to get to the developers (of either or both of DosBox and evdev) for this to be troubleshooted. If anyone has any suggestions on how to go about this, I would appreciate it!

Try the SDL_VIDEO_X11_DGAMOUSE env var (use google for some info about it).

wd wrote:

Try the SDL_VIDEO_X11_DGAMOUSE env var (use google for some info about it).

Thanks, this turned up a LOT of related information!

Can you pinpoint something that helps? Disabling the DGA mouse using that sdl env var?

wd wrote:

Can you pinpoint something that helps? Disabling the DGA mouse using that sdl env var?

A workaround that helps in my situation is to launch dosbox (in Ubuntu linux) from a terminal console by typing first:

1export SDL_VIDEO_X11_DGAMOUSE=0

and then

1dosbox

(FYI ...This does NOT work for me if I type the first command in the terminal and then launch dosbox from the gui; both have to be done from the terminal.)

So far I haven't found anything else that works other than using the standard mouse driver instead of evdev. From what I have read over the last few hours, this appears to be a bug in xorg 1.4, although in some places (here, for example) it's reported as a libsdl bug: https://bugs.launchpad.net/ubuntu/+source/lib … 1.2/+bug/189958

This doesn't appear to be a DosBox problem.

Some time ago i've tried to figure out if disabling the dga layer would have
any bad effects, but the only relevant threads that i could gather mentioned
that dga is only needed for high-frequency mouse stuff (which dosbox might
not be).
If you have any idea about it, we might consider just disabling the dga mouse
by default.

wd wrote:

Some time ago i've tried to figure out if disabling the dga layer would have any bad effects, but the only relevant threads that […]
Show full quote

Some time ago i've tried to figure out if disabling the dga layer would have
any bad effects, but the only relevant threads that i could gather mentioned
that dga is only needed for high-frequency mouse stuff (which dosbox might
not be).
If you have any idea about it, we might consider just disabling the dga mouse
by default.

I don't know enough about the situation yet to have an opinion about whether the dga mouse should be disabled by default. But I think that the situation affects enough people that the workaround and reason for it should be listed in the DosBox FAQ. (If it already is and I missed it, I apologize.)