You check the refresh rate?

I'm not sure what you mean by that...

I meant did you set the pointer refresh rate.

The different axial speeds are intentional; the game is specifically changing the mickey/pixel ratios depending on the resolution. Try this:

1    case 0x0f:   /* Define mickey/pixel rate */
2+      LOG_MSG("Mouse mickey/pixel ratio horiz=%u vert=%u",reg_cx,reg_dx);
3-      Mouse_SetMickeyPixelRate(reg_cx,reg_dx);
4+      Mouse_SetMickeyPixelRate(reg_cx,reg_cx*2);
5       break;

The log message shows what the game is using for ratios when the resolution changes. By forcing the ratio to vertical=horizontal*2, you should get close to equal speed on both axes in all resolutions; however, it will only be "ideal" in 320x200 and 640x400 because the resolution ratio matches the default mouse ratio more closely. Not a "fix", just something to play with.

I'm still planning to try it on a real machine first, because it seems crazy that the game would be intending for it to behave that way.

You get the same thing with real mouse drivers, although you may not "feel" the slow axis as much because of their acceleration... DOSBox's mouse has a more "flat" response without acceleration. The game does use a double speed threshold, and I'm not sure how accurately that's simulated with DOSBox's internal driver, however it's effect is equal on either axis.

ripsaw8080 wrote:

By forcing the ratio to vertical=horizontal*2, you should get close to equal speed on both axes in all resolutions; however, it will only be "ideal" in 320x200 and 640x400 because the resolution ratio matches the default mouse ratio more closely.

Actually it feels ideal at 640x480 and weird everywhere else. Why is that?

By "ideal" I mean the normal (default) ratio. At 320x200 the change I mentioned will use h=8 v=16, which is equal to the default ratios, and what you usually get in most games at that resolution.

A similar discussion came up recently regarding Ultima 8, which uses non-default ratios. I theorized that it serves a purpose based on how the interface works for moving the Avatar around, but it's awkward when trying to use the mouse to click on stuff in the display. You'd have to ask the System Shock programmers why they chose the ratios they did. Try that log message I mentioned and you'll see some of the seemingly strange values they use.

By "feels ideal" I meant that moving the mouse in a circle moves the cursor in a circle at 640x480. "Weird/strange" means that moving the mouse in a circle produces noticeably oval-shaped (with the major axis oriented vertically) cursor movement at all other resolutions.

I should also mention that I've been running at 640x400 because the UI has some stretching artifacts at 640x480 due to not being an integer multiple of 320x200.

I also just found out about System Shock Portable. I should probably check that out since it actually supports mouselook.

I like to use 640x400 because it preserves the UI appearance while doubling the resolution of some elements and the main view. I was annoyed with the strange mickey/pixel ratios the game uses, and some time ago made a TSR that applies the normal 8,16 ratios to 320x200 for startup screens, and 1,2 ratios to 640x400, because they give the feel and speed I'm used to.

There are mods for CD System Shock that add higher resolution VESA modes. It's quite possible the mickey/pixel ratios were tweaked as part of those mods.

Setting dosbox.conf autolock=false seems to do the trick as well, even in full-screen.

well, when you press ctrl-f10 to lock manually, it should then behave the same as autolock. I guess you're not manually locking? The reason is that emulate=false when the mouse isn't locked.

Correct. When I ran with autolock=false and didn't manually lock, everything was fine. When I manually locked via ctrl+f10 it switched to the other behavior and felt weird.

I still have that similar problem that I described some time ago with DOOM/DOOM2/Heretic/Hexen. The workaround that I've been using is to load the Cute Mouse Driver (CTMOUSE.EXE) before running those games... works like a champ 😀

Hmm interesting idea, I'll have to try that. Thanks!

Well, CuteMouse has quite strong acceleration compared to DOSBox's "flat" response, so that probably compensates for any sluggishness. DOOM et al use the mouse very differently than System Shock, and I guarantee CuteMouse pays attention to the mickey/pixel ratios. Didn't you also find that your problem could be fixed by changing to the WINDIB driver, so there was some SDL/DirectX issue?

ripsaw8080 wrote:

Well, CuteMouse has quite strong acceleration compared to DOSBox's "flat" response, so that probably compensates for any sluggishness.

I doubt that it would be enough to compensate for the vertical cursor movement speed being at least 3 times as fast as the horizontal speed in 320x400.

ripsaw8080 wrote:

Didn't you also find that your problem could be fixed by changing to the WINDIB driver, so there was some SDL/DirectX issue?

Nope, results were inconclusive. IIRC that (WINDIB) didn't help at all. But... the problem _sometimes_ seemed to be hard to reproduce, other times it would happen consistantly (like just now, as a matter of fact). In any case, I have the problem more times than not, so's I simply got used to loading in CTMOUSE every time for those games.

HunterZ wrote:

I doubt that it would be enough to compensate for the vertical cursor movement speed being at least 3 times as fast as the horizontal speed in 320x400.

I think that CTMOUSE just might be the ticket for ya. In DOOM/DOOM2/Heretic/Hexen on my PC, the horizontal movement is so damn slow I can't hardly do anything.

On a regular DOS PC, I usually set the game's mouse sensitivity so's that I can rotate 360 degrees in a little less space than the width of my mouse pad. This is how I've been use dto playing those games on a DOS PC for eons.

Under DOSBox, when the problem is happening, I'd need a mouse pad that was about 2 feet wide to do the same thing 🤣! But... I load in CTMOUSE, and it feels *identical* to how it felt when I played under a DOS PC, with the same horizintal response 😀

You're using the acceleration of CTMouse to compensate for the sluggish horizontal speed with DOOM (I wrote a utility to allow a user-selected speed, including 0 for the vertical because moving the mouse up and down for forward and backward is not as useful as turning). Its acceleration is equal on both axes, so it's not going to take unequal speeds and make them equal, it's just going to make them faster.