The attached source patch appears to resolve the issue with text screen dimensions when the mouse is unlocked, but only for the internal mouse driver. Maybe there are games that can benefit from it, but at this point I know of none.

Would this go alright for different character heights as well ?
Otherwise I think it would be an improvement as we get rid of the usage of the videomode structure

My first thought was that character height would figure into it, but it appears not to, haven't worked out why exactly. Needs some testing in any case.

Thanks ripsow8080! The code looks PERFECT for solving the problem. (Now I just have to figure out C compiling on a Mac -- yikes.) I'll look forward to the stand alone release that incorporates it, in any case.

First, a thousand thanks to ripsaw for tackling this problem.

I built my custom solution with this patch applied, and had mixed results, unfortunately. All of these notes apply to a custom build based on SVN with output=openglhq, and running DOSBox in a window under Windows XP.

Running a text-based program in what the program calls "Paradise VGA Plus 132x43 16 color mode," the mouse refuses to go into the first line of text, and sometimes won't scroll above the fifth or sixth line of text.

Running the same program in a custom 43-line x 80-character mode that I built into my project (it uses standard size VGA fonts, but in 43 lines instead of 25), again the mouse won't go into the upper few lines of the screen.

Running the same program in graphic mode with the program's VESA driver, at 1024x768, the mouse usually won't go into the right-hand two-thirds of the window. When I do somehow manage to get it into the right-hand part of the window, and click the mouse, the click gets passed to the window behind the DOSBox window, which comes to the front - with, weirdly, the mouse cursor from the DOS app still visible, though it now doesn't do anything. (I hope this is clear.)

Even more weirdly, these results are not entirely repeatable. Sometimes the mouse can get into the right-hand third, and sometimes it can't. I can't make head or tail of this, but it resembles what I experienced before the patch.

I hope this is of some use in sorting this out.

The patch will only have an effect on modes that are recognized as text modes (note the CurMode->type == M_TEXT condition), graphic modes are unchanged. So far I've only tried the patch on variations of mode 3 where the BIOS row and columns are set correctly.

That's what I get for acting fast without thinking. The patch does work perfectly in 25x80 text mode. I'll hope (knowing I can't actually ask for it!) for similar results in other text modes someday, but I won't be impatient about it. Meanwhile, if you see anything obviously wrong in my rewritten version of mode 3 (with 43 lines), I'd be very grateful to know:

1{ 0x003  ,M_TEXT   ,720 ,688 ,80 ,43 ,9 ,16 ,8 ,0xB8000 ,0x4000 ,100 ,688 ,80 ,688 ,0	}, /* 43-lines! */

You shouldn't change mode 3, it's a standard mode. You can, however, *alter* mode 3 at runtime, such as by switching to the 8x8 font (80x50), or the 8x12_50 TSR.

ripsaw8080 wrote:

You shouldn't change mode 3, it's a standard mode. You can, however, *alter* mode 3 at runtime, such as by switching to the 8x8 font (80x50), or the 8x12_50 TSR.

I know you're right though I've been reckless about doing it anyway for my project, because I have some software that only runs when it detects "mode 3", and I was able to get it to run with my 43-line fake mode 3, and it wouldn't run any other way in more than 25-lines.

My earlier method was to use the line that I listed as mode 3 as "mode 59," and use a custom internal "43LINES" command in the [autoexec] section to switch to mode 59 on startup. But at least one utility wouldn't run in "mode 59" - but would happily run in exactly the same 43-line mode if it was named "mode 3" instead of "mode 59." (I used a similar trick to create a 43-line monochrome mode, complete with the underline attribute.)

Probably what I'm doing here is so incompetent that I shouldn't even describe it in public, but it seems to work fairly well in my project - though probably not in any other situation at all.

SUCCESS! (At least for me!)

After hours of haggling I finally taught myself to be enough of a developer to compile DOSBox from source. I haven't tried ripsaw8080's exact code, but, since I had just one simple need, I just changed the one line in mouse.cpp...
from this: mouse.y = y*CurMode->sheight * 8 / CurMode->cheight;
to this: mouse.y = y*CurMode->sheight * 16 / CurMode->cheight;

Works like a charm for 80x50 text mode! A fully functional 80x50 UNLOCKED mouse. Tomorrow I'll try to figure out the "Real" fix, which will also work with 80x25, and, I would hope 80x43. (I'm sure it will call NB_ROWS as ripsaw8080 suggests, or something like that.)

By the way, quick question for ripsaw8080: Could the intermittent results some reported with your patch be due to making BIOS calls so often? (Everytime the mouse relocates?) Being brand new to DOSBox's source code, I'm not sure if those are actually polls to the BIOS, or simply DOSBox variables. (Perhaps they are one-in-the-same, since we're emulating and all.)

Anyway, thank you all SO much!
-MH

Could the intermittent results some reported with your patch be due to making BIOS calls so often?

The results aren't intermittent. The problems emendelson mentioned are with non-standard text modes he is using with his custom build and graphics modes that are not addressed by the patch.

Why not just try the patch as posted and report your results? It's only changing two lines of code...

Yes, I confused the issue with my custom modes; apologies again. The patch works absolutely perfectly with standard text modes.

(And just to explain the point of those custom modes: they use the standard VGA font in more than 25 lines, instead of using a smaller font as in the 8X12_50 solution. My users complained that the 8X12_50 and similar BIOS fonts were too small to read easily, and they weren't comfortable for me ether.)

ripsaw8080: You're right. Your fix is perfect as is; works in all text modes (that I can test), and with the normal font set and 8X12_50. You're a lifesaver!

-MH

@emendelson @mhaigler: Thanks for the feedback.

At some point I'll look at a more comprehensive patch that includes the non-standard stuff and graphics modes. For anyone interested in fiddling with it, an important thing to understand is that the CurMode struct only contains info from the mode table -- it is unaware of how a mode is subsequently modified (tweaked) after it is set. In the case of text modes, the screen dimensions can be changed and a different font can be loaded. In some cases, as with the patch I posted, more accurate info can be taken from video BIOS memory values.

Thank you in advance for any help with this. You've already helped enormously.

So, could someone sum that up and make some ready to use files?

I have the same problem: when in fullscreen mode, my original Master Of Orion has no issues with mouse pointer. But when windowed, then I can't access the bottom part of window with it; unless I lock with CTRL+F10

And I wish to be able to play MOO in windowed mode but with the ability to move the cursor out of DOSBox window to access the Taskbar, Winamp etc.; and then go back to it, without the need to use keyboard to change anything

Post is from 2013, don't necropost, make a new thread instead please!!

lightmaster wrote:

Post is from 2013, don't necropost, make a new thread instead please!!

Sorry

Here it is then: Mouse pointer does cannot access bottom of windowed DOSBox