So called "abandonware" is not supported on vogons.
To post issue on games on this forum post and only provide info on using the latest official version of DOSBox from sourceforge with a legally acquired game.
If a game was purchased from GOG then a ticket should be opened with GOG since if you paid money for it then you should get support for it.

Hi,

So I'm having an issue with a number of games and nobody appears to be able to know how to solve the problem and maybe someone can give me a nudge in the right direction of where to investigate.

I first noticed it recently in my copy of Lords of the Realm 1 from GOG. Both GOG Support and GOG Forums have no help for this and I do not think it specifically has anything to do with their version or how they set it up through configurations. I own a vast library that utilises DOSBox w/ GOG and my own collection of old games, but I cannot pinpoint why this issue crops up in seemingly random games when most of them seem to work fine. The issue happens from game launch and will persist the entire time.

I have seen this problem in the past and there have been random tools that attempted to alter this (I believe mouse2k? was it?).
The relevant configurations I see do not even allow setting the mouse sensitivity on each axis different in one axis than the other.

I do not have my old system setup that I setup a few of my old games I could run off of DOSBox as Windows 98/XP era shifted to 7 then 10, but this issue was apparent then on 'random' titles too.

So I'm at a bit of a loss. Everything I am testing is in DOSBox .74. The machine running this has a 2000s series RTX Nvidia card and an i7 in it with 32 GB ram. I'm not those details are particularly useful as I have seen this exact same issue on other.

In this case I've tested LOTR1 w/ 1024x768 windowed with openGL and another game at 640x480 w/ overlay.

I apologise for the other post here and cannot DM people to clear up anything about details regarding the other posts. I just wanted to share multiple examples of how I can reproduce the issue despite these config files having nothing I can see that'd be altering the mouse input.

If someone has some ideas, greatly appreciated! I can provide more details, such as gameplay but I'm not sure what other details would be useful. Would the DOSBox config be useful? Thank you.

Thread unlocked on the assumption that ONLY purchased copies of games are being used.
This forum is not for testing of games that are acquired via other means.

List all of the games (you mentioned a number of games) that you are having the issue with.
Try the latest version of DOSBox from sourceforge with a default config.
Try an SVN version of DOSBox with a default confg.
See: https://sourceforge.net/p/dosbox/code-0/4197
Try Cutemouse

Let's work with Lords of the Realm 1 because now I have several folders of DOSBox installs testing things. I have opened another ticket with GOG for support and if something comes of that I'll update on that end.

I backed up what GOG installed, which appears to be mostly the original game files + a DOSBox .74-2 installation folder. Nothing too fancy and I looked again to make sure no mouse.exe or any mouse altering program already existed in these directories. Nope.
I did some thinking and confirmed again by comparing in the game window vs. in windows, carefully moving the mouse with the same motion, the Y direction is 50% of the expected motion. If you move from the bottom left corner on a diagonal, you'll end up at the middle right edge of the game window when you feel as though you should be top right.

I downloaded DOSBox .74-3 and setup another environment for DOSBox fresh. I ran the reset options command within. I renamed all the DOSBox config files in the main game's directory and dragged LORDS.exe over to the newly installed DOSBox's directory. I noted settings as it loads are default (3000 cycles instead of max) and the application says the newer versionn. It also won't launch the other DOSBox without those configs setup, so I'm confident it's running both the new version and a default config file. Unfortunately, I am still getting the same mouse behaviour.

I took a look at cutemouse and extracted that within the game directory and mounted the game directory. There are no instructions, but I went on the assumption you run one of the \bin files (presumably the English one), and it said PS/2 driver installed. I ran this with the freshly installed DOSBox .74-3 with default config. Ran the game after running that through the DOSBox command prompt and the mouse appears to have changed sensitivity (more sensitive) but still behaves the same. I think here I am missing a command/config to slow down X or increase Y.

I had a weird hunch that maybe this has to do with unusual registry settings regarding the mouse. I checked the mouse thresholds in HKEY_CURRENT_USER\Control Panel\Mouse . Learned one is related to 'precision' mouse control. Tried it both on and off and searched through those registry keys for anything unusual as well and I do not see it. I'm just beginning to think this is an interaction of how mouse movement is being translated and it's not specific to any game.

I had the thought to try Wing Commander (also setup via GOG) which 'seems' to track better, but the mouse's sensitivity in the game itself (it's set to 100 in the config) is so tiny in the menus that it is difficult to tell if it's behaviour is correct or not. The game is largely setup for a gamepad / joystick I feel and that was a poor example.

I'm now curious to attempt to run this LOTR1 on another machine when I get another chance to work on this to see if the X/Y tracking is likewise off on that to isolate that it's not a condition being imposed by this operating system's relationship to DOSBox.

A DOS program can query the mouse in various ways, but the most important distinction is that it can look at mickeys and at pixels.
The ratio between mickeys and pixels is different between the X and Y direction.
To be precise 8 and 16. Which might be your perceived difference between X and Y or not. But you might be able to write a tiny tsr that sets it to 8,8 (int 33, regax = 0xf, cx=8,dx=8) at a specific point in the game.

However most of the time, you won't feel the difference, as the X resolution (of the mouse, not the screen!) tends to be 640 and the Y resolution 200. ( which is for a 320x200 (screen resolution), double the X coordinate)
And of course a lot of games interpret the mouse movements themselves with their own formula.

So the first thing you would need to establish is what those games are looking at. (own/driver and pixels/mickeys/both (yes both is common as well, hence you can't just change the numbers))

But there is not a 1:1 relationship to what you input at the front and what ends up in the game and a part of that is by choice of the game programmers themselves.

I remember there used to be a debug window in DOSBox that ran alongside it. Is there a way to see this divergence in an output to confirm that?

That sounds like a very strong hypothesis as to what is happening. It's 'seemingly random games' unrelated to configs or anything and does not seem to care about the system running DOSBox physically.

I did some testing today with other offshoots of DOSBox (I never knew these existed!...and they all call themselves DOSBox [add a name] so naturally confusing). I was able to address the issue in LOTR1 and tested it by using default config this fork of DOSBox ships with + using their altered sensitivity option where sensitivity=50,100. (x,y in %) It may not be absolutely perfect (it passed the play for 5 minutes test at least!) but it feels a lot more correct and accurate to how I know the games behaved 20+ years ago.

DOSBox SVN (latest official source) has the axial sensitivity=x,y setting. Multiplying (sensitivity=100,200) rather than dividing (sensitivity=50,100) may be preferable in some cases, it depends on what the game does with the position data.

Yeah I figured it's a little bit of testing. Is this the prescribed way to deal with these kinds of issues now? (Sounds good to me! I just like to be able to speak of / spread the conversation of 'well is this accurate? Is it and if not how is it not?' as well. So this conversation has been helpful as I wasn't aware there were different layers/go-betweens used on these DOS programs as it's not something you usually see unless it breaks down like this.)

Please forgive my naivety, I saw the SVN and it appeared to also be .74-3 or .74-2. How do I get the latest SVN version? The page linked here brought me to the latest revision of a particular file and there's no direct link/url to svn/https pull the files. If I back up to another directory, it's a different revision.

Thanks again for the help everyone!

Is this something I need to compile myself? I've used SVN, but I think the presentation on the website is confusing me. I checked branches/trunk/tags and I just see things similar to the released versions.