A followup, since I've been able to repeat the bug, and someone out there may be able to understand it. Upon rapidly moving the mouse back and forth, it crashed the game more times than it did dosbox. Here is one produced in Riddle of Master Lu.

It's the same result each time, but so far Riddle of Master Lu is the only one to produce an error report, a two second burst of quick movement from the mouse is all it takes to crash dosbox. I am literally running barebones, no background programs whatsoever, not even a virus scanner and the result is still the same.

Bugs that can be reproduced are always welcome 😀

Not sure if it will help, but try downloading the latest experimental version of DOSBox: http://builds.tharos-online.de/index.php?dir= … date&order=desc

If you are lucky, something might have changed since 0.72 that fixes this bug.

Hello Mini, thank you for the reply. I am willing to try it, but I don't think it will work, because if you read above the bug has also began reproducing in DOSBox 0.65, that I still have installed, only difference is that 0.65 produced no errors, simply crashed upon a swift jerk of the mouse.

As expected, it didn't, downloaded and extracted and ran as was and it still happened. Used my old .conf file from 0.72 and same thing. I'm stumped.

Try the game with core=normal in dosbox.conf.

All that did was delay the bug, it took me rapidly shaking the mouse for a good 15 seconds this time before the crash appeared. Here's the report in Riddle.

[/img]

Use some fixed cycles= value, revert the core= setting.

Core reverted to auto, cycles set to 3000. Neither the game nor dosbox crashed after 60 seconds of shaking the mouse back and forth, but with every moment it made, DOSBox and the game would resume the freezeframing and jerkyness, both visually and through sound. If I had some method of recording I'd attempt to do so.

so try 30000...

Same thing on 30000, did not crash the game or dosbox, but the game and dosbox still freezeframes visually and in sound with each movement of the mouse.

Maybe 30001 ?

Not very helpful.. 🤣.

Force_Phenomenon wrote:

All that did was delay the bug, it took me rapidly shaking the mouse for a good 15 seconds this time before the crash appeared. Here's the report in Riddle.

Sounds like the Dos/4GW mouse bug. Try the alternate DOS extender DOS/32a version 9.12 as a test replacement for your current DOS/4GW version.

What is the DOS/4GW version that came with 'Riddle of Master Lu' that is displaying the Dos/4GW errors that you posted?

Best of luck,

dvwjr

dvwjr wrote:

Sounds like the Dos/4GW mouse bug. Try the alternate DOS extender DOS/32a version 9.12 as a test replacement for your current D […]
Show full quote

Force_Phenomenon wrote:

All that did was delay the bug, it took me rapidly shaking the mouse for a good 15 seconds this time before the crash appeared. Here's the report in Riddle.

Sounds like the Dos/4GW mouse bug. Try the alternate DOS extender DOS/32a version 9.12 as a test replacement for your current DOS/4GW version.

What is the DOS/4GW version that came with 'Riddle of Master Lu' that is displaying the Dos/4GW errors that you posted?

Best of luck,

dvwjr

I don't know what the version is, I assume it would be whatever was current at the time of 1994 and 1995, since that was the game's production and release time period. But, it is not just during any game, the mouse bug affects dosbox itself, anything ran in it experiences the same problem, regardless of what version I am using. I don't know what's been changed to cause this, but I did not have this problem when I first began using DOSBox.

Try core=normal with DOSBox 0.65 and see if that works. IIRC, core=normal is the default for 0.65. Can't really remember. (You can verify by installing it, deleting the dosbox.conf and then typing "config -wc" inside of DOSBox to generate a new DOSBox.conf).

DosFreak wrote:

Try core=normal with DOSBox 0.65 and see if that works. IIRC, core=normal is the default for 0.65. Can't really remember. (You can verify by installing it, deleting the dosbox.conf and then typing "config -wc" inside of DOSBox to generate a new DOSBox.conf).

Normal was already set as the core value in the 0.65 .conf file, but I generated a new one anyway, had the normal value and the same bug continues to repeat, regardless of the version of DOSBox. The first thing that comes to mind is a software confliction, but.. I don't know what would cause it.

Force_Phenomenon wrote:

I don't know what the version is, I assume it would be whatever was current at the time of 1994 and 1995, since that was the game's production and release time period.

Try typing DOS4GW.EXE at the DOS prompt in DOSBox v0.72 to get the DOS/4GW version number. Also, check the size of the DOS4GW.EXE file and post that information also to help narrow down the problem.

Force_Phenomenon wrote:

But, it is not just during any game, the mouse bug affects dosbox itself, anything ran in it experiences the same problem, regardless of what version I am using. I don't know what's been changed to cause this, but I did not have this problem when I first began using DOSBox.

Do you have the same mouse problem with a real-mode only game, or only protected mode games in DOSBox? Try the DOS/32a replacement to see if any protected mode game mouse problems are resolved, or not...

I run a BFG nVidia 7950GT with the 91.47 drivers on WinXP (SP2), so I'll have to pick up a copy of the 'Riddle of Master Lu' game to see what is happening. A simple adventure game should not have mouse problems, however the mouse callback code of the game might be marginally coded. 😦

dvwjr

dvwjr wrote:

Try typing DOS4GW.EXE at the DOS prompt in DOSBox v0.72 to get the DOS/4GW version number. Also, check the size of the DOS4GW.E […]
Show full quote

Force_Phenomenon wrote:

I don't know what the version is, I assume it would be whatever was current at the time of 1994 and 1995, since that was the game's production and release time period.

Try typing DOS4GW.EXE at the DOS prompt in DOSBox v0.72 to get the DOS/4GW version number. Also, check the size of the DOS4GW.EXE file and post that information also to help narrow down the problem.

Force_Phenomenon wrote:

But, it is not just during any game, the mouse bug affects dosbox itself, anything ran in it experiences the same problem, regardless of what version I am using. I don't know what's been changed to cause this, but I did not have this problem when I first began using DOSBox.

Do you have the same mouse problem with a real-mode only game, or only protected mode games in DOSBox? Try the DOS/32a replacement to see if any protected mode game mouse problems are resolved, or not...

I run a BFG nVidia 7950GT with the 91.47 drivers on WinXP (SP2), so I'll have to pick up a copy of the 'Riddle of Master Lu' game to see what is happening. A simple adventure game should not have mouse problems, however the mouse callback code of the game might be marginally coded. 😦

dvwjr

There wasn't an executable in the Riddle of Master Lu folder for DOS4GW. And this problem occurs when starting up dosbox alone, I can capture my mouse while in just the command prompt, and moving my mouse back and forth there causes freezeframing since it causes intermittent interruptions in the blinking in front of the command prompt. This happens in every game I play and every program I run. I've uninstalled both DOSBox's and reinstalled them fresh, both one at a time and back to back, ran them seprately at each time and this bug continued to plague me. As I mentioned before, both DOSBoxes used to run perfectly, I played through Riddle of Master Lu on both until my year long break. During that time a driver or softtware update is the only thing I can think of that would cause this error. I am stumped as to what version of my NVIDIA drivers I'm using, it's the latest set off their site, that's all I know. My Creative X-Fi drivers are up to date as well. I have the latest Logitech Setpoint drivers and software and all the latest G15 drivers and software.

Not very helpful..

So you can raise the cycles count on your own now?