I know.
Debugged a few times, but didn't find the problem

I was supprised about the lack of info on the web I could find about this, its a very good game, thought more people would want to get it working.

Maybe try with a fixed cycles setting, for example cycles=10000 .

directserial mouse works fine:
I noticed that on pressing R the directserial mouse is being reset to the center of the screen and when you move it, it is starting from the center of the screen.

Dosbox's emulated mouse is not always being reset to the center of the screen and also it not always starts from the center or even the place of reset. (if you moved the mouse it is most visible)

I guess the dosbox's mouse is constantly being probed even while the screen is changing resolution hence its strange coordinates.

A possible solution could be to pause mouse probing from the moment resolution change has started and continue mouse probing when the screen is already completely reseted in new resolution.

now i noticed a solution:

if you release a mouse before resolution change and lock it again after the change everything is ok.

so just auto unlocking the mouse before resolution change and autolocking it after that will solve the problem

yeah moving the mouse during the switch seems something that game doesn't like.
However in most mouse drivers there isn't a timer that keeps the mouse disabled for the duration of a mode switch.

also if you use autolock=false you can move the mouse cursor out of the dosbox window for the moment of resolution change

i think mouse drivers are just reseting mouse position to the center of the screen after any resolution change

check the svn log for mouse.cpp for more on that 😉

http://dosbox.svn.sourceforge.net/viewvc/dosb … se.cpp?view=log
read it and don't know what you mean

Well the mouse driver is a tricky piece. Changes for one game, break another.

We did have that centering of the mouse driver in DOSBox earlier. However, it seems to break Stonekeep.
Topic 11497

Not even sure if the centering is the solution for this game.

I analyzed this mouse issue with Theme Park, and it looks like a game bug to me, where because of the mode change it forgets to clear its non-reentrant flag in the mouse handler. Mouse events continue to be sent to the handler by DOSBox, but the non-reentrant flag has locked out processing of the events.

When browsing the change for stonekeep. I noticed that I clear all events and remove the busy timer for the mouse delay.
If the game were to act on mouse down (instead of mouse up), then it might be surprised the quickness of of the mouse up event as that one isn't delayed. Not sure if that has anything to do with the problem though.

The INT 33/0C event flags are CX=0x7f, so the UIR is called for mouse movement, button presses, and button releases. However, the problem occurs from just mouse movement during a mode change, so why do you think button up/down could be a factor?

the fact that mouse UIR is called earlier than "normal", because the delay isn't there (as set new mode removes it)

This is starting to go over my head, but am I to understand the problem is related to the mouse drivers?? How would these drivers work different if they were in a natural dos environment??
Just curious 😀

when mouse is not locked mouse also freezes when tapping R a lot
after tapping some more mouse pointer is no longer visible at all.

btw you don't have to use mouse in this game to load save state 2.
end of the year screen disappears itself without clicking after some time. But with low cycles you won't even get to it.

I even once started the game and mouse was not working at all, I didn't even changed the resolution. It looks the mouse problem may happen anytime, and changing resolution makes it more probable and moving the mouse that moment make it even more probable.

when tapping r a lot it happens in virtual pc and on real 386 too. Although i noticed virtual pc is always unlocking the mouse on resolution change so you have to click to lock it every time.