[MOVED]

I upped the mouse sensitivity in the DOSBox configuration file to a higher value and that helped somewhat with this problem, but the game still ran somewhat slowly and it wasn't really playable.

I then tried the game in Virtual PC and the game runs okay with that, but the character movement/animations were rapid and a bit jerky, making me feel like they were getting ready to have a seizure...

If anyone figures out truly workable settings for this game in DOSBox, please post. 😀

FWIW, I noticed that using a fixed cycles setting make to mouse movement slightly better. For example, try using 30000 cycles together with a mouse sensitivity of 300+. Tricky game indeed. Makes you wonder how hard it was back in the days to get it working nicely on a machine of the time.

Thank you; I tried that, and it does help some. What really deters me from trying to play the game this way, though, is that if I recall correctly there is at least one timed puzzle that needs to be executed swiftly; I have a feeling that could prove to be quite problematic.

I played this game when it was first released, and had no problems at all with it in terms of performance. Hopefully at some point it will run optimally in DOSBox. 😀

It doesn't fix the issue for me... 🙁

Leo, make sure you are running on the dynamic core.

I did it and nothing change...

I think i found a good solution for this game to make it "playable". I followed the instructions described above. Cycles 30.000+, Core:Dynamic and mouse sensibility 300+ (and mouse autolocked) seems to help a lot. But that all is going to help only if you have the patch for the DOS version of the game. Otherwise the game keeps freezing in the options menu right after the first introduction and the titles.
I apply here the Patch for the english, german and french version of the game. All you have to do is:
1) Install the game
2) Apply patch in the installed game Folder
3) Run the patch exe file and play! 😀
4) Don't forget the mouse and core/cycles settings.

http://www.megaupload.com/?d=NZOBWGS4

P.S. If somebody finds a better configuration than the ones described in this thread just let us know 😀

After some investigation into why this game is so unresponsive to mouse movement in DOSBox, I could not find a clear problem, but learned of a way to improve response. A control system is used that periodically repositions the mouse coordinates to 320,240 (center of the 640x480 video resolution), and mouse movement away from the center point is used to control turning. How often the coordinates are read versus how often they are recentered has a considerable effect on response. The read/recenter ratio could be off due to a number of things, including timing issues in DOSBox and low system performance; but in any case, the control system can be externally influenced.

I made a program that reduces recentering by allowing a specified fraction of the mouse driver calls to pass, dropping the rest. The program, which should be placed in the ATLGAME folder, takes a parameter of a rate divisor and launches ATLDOS.EXE with reduced recentering. A parameter of 2 will cut the recentering calls to half, 3 to a third, and so forth. Cutting the recenter rate too much can give the mouse control a loose feel because this workaround trades off how quickly movement is arrested for increased response. Experiment with combinations of cycles, mouse sensitivity, and rate cuts to find what works best for you. Source code is included in the attached archive.

If you're on Windows you could also try playing it in windowed mode (see this thread).

It makes little difference for this game. Even cranking mouse sensitivity to very high levels has little effect on the in-game control, although the pointer in menus is changed by the sensitivity. Try a rate cut of 10 or more; it will make a very noticeable difference in response.

Mouse responsiveness is much more finegrain in dosbox than for old mouse
stuff, at least ps2 mice had a (by default rather low) sampling limit.
Would the game exhibit the same problem in that case on a real system?

Dunno, but I can say that the game does not use a handler driven by mouse events, where the rate of the events could be a factor. It polls with function 3 and re-positions to center with function 4 on its own internal schedule. My theory is that the recentering is done on a timer, while reading coordinates is done by the main game loop. Low performance could therefore cause the amount of reads to be out of proportion to the recentering. The game is from 1997 when ~200 Mhz Pentiums were not uncommon.