VOGONS

Common searches


First post, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

On one of the desktop which has 2560x1440 monitor with Windows 10 display scaling at 125%, mouse cursor malfunction and usually moved itself diagonally and got stuck at lower right corner. The mouse cursor would behave normally by resetting Windows display scaling to 100% or override the high DPI compatibility to "Application", essentially making display scaling disabled.

DOSBox SVN was a WIN64 build as I found that Windows 10 display scaling does not apply for WIN32 build. WIN64 DOSBox would display the message on the console "Windows dpi/blurry apps scaling detected! The screen might be too large or not show properly, please see the DOSBox options file (fullresolution) for details". Since DOSBox ran in windowed, everything was display properly with scaling, except the mouse cursor. DOSBox option "autolock=true/false" does not make any difference. I don't know how to make Windows 10 display scaling applied to WIN32 DOSBox, so I am not sure if WIN32 build would have the same issue. Changing high DPI compatibility does nothing to WIN32 DOSBox. I don't know why WIN32 DOSBox was magically excluding from display scaling since on QEMU both WIN32 and WIN64 builds are subject to display scaling.

Tried several games, Dune 2, Warcraft 1 and several Sierra Online point-n-click adventures.

Reply 1 of 29, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Did you try the SDL.dll from 0.74-2 with your build ?
We use intentionally an older SDL.dll for some mouse related issues.

Water flows down the stream
How to ask questions the smart way!

Reply 2 of 29, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

The MSYS2/mingw-w64 ecosystem comes with its own SDL. Wasn't the official DOSBox build only support WIN32? Anyway, I will check it out when I get a chance. As I always said, I couldn't get display scaling applied for WIN32 DOSBox, and I don't currently have system with Windows 10 32-bit version to see if display scaling would be in effect there.

Reply 3 of 29, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

nah, it doesn't I have an influence (at least with the sdl from 0.74-2). I have it disabled and enabled reguarly at my place for dosbox, using the exe properties or by a manifest. Messed around with the display scaling a lot before the release.

Water flows down the stream
How to ask questions the smart way!

Reply 4 of 29, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

Testing the display scaling is a PITA.

Can you post steps to recreate? (Also be aware of your video card scalings as well when testing)

It looks like Microsoft is changing this yet again in their beta OS:
https://wccftech.com/windows-10-2019-build-emoji-12

High DPI Improvements As many of you know, we’ve been working over the past few years to improve the High DPI story for Win32 ap […]
Show full quote

High DPI Improvements
As many of you know, we’ve been working over the past few years to improve the High DPI story for Win32 apps on Windows. As part of this, some of you may recall getting a toast about fixing your apps that led you to this setting we added with Build 17063:

In 19H1, we’re enabling this setting by default, to help automatically address some of your scaling feedback, and reduce the number of times you see that “Fix blurry apps” notification.

We’d love your feedback! Notice that some of your apps seem blurry after docking/undocking, or other mixed DPI scenarios? You can let us know by reporting it here!

If you’re interested to learn whether or not an app is DPI aware you can find out using this feature we rolled out to Task Manager a few flights ago.

How To Ask Questions The Smart Way
Make your games work offline

Reply 5 of 29, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
DosFreak wrote:

Can you post steps to recreate? (Also be aware of your video card scalings as well when testing)

This should be simple. Change the display scaling in Windows 10, recommended to start with 125%. Run DOSBox, check DOSBox console for the following message:

"Windows dpi/blurry apps scaling detected! The screen might be too large or not show properly, please see the DOSBox options file (fullresolution) for details".

That tells that Windows 10 display scaling is in effect. If you don't get this message, then display scaling did not apply and mouse cursor would behave normally.
Run any point-n-click games, Dune 2, Warcraft, Sierra On-line etc.

I can only build DOSBox with MSYS/MinGW (WIN32 only) or MSYS2/mingw-w64 (WIN32/WIN64). WIN32 version does not get display scaling, WIN64 version does. I don't have VS to check out WIN64 build from VS or WIN32 build from VS.

Reply 6 of 29, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

Compiled builds from May 2018
https://drive.google.com/open?id=1G13rkLjYDDv … VZfop3aMO8U9mvV
Builds are static with latest SDL 1.2 branch at that time so can't test with standard SDL.

Windows Build 1803
1. Right-click desktop ->display settings-Set scaling to 125%
1. Put MS-DOS edit.com in same directory as DOSBox.
2. Launch dosbox
3. Type in edit.com
4. When mouse is captured by DOSBox then cursor will be locked to bottom right corner of screen with autolock=true. With autolock=false you can briefly see the cursor move. Occurs on both 32bit and 64bit builds.

0.74 or 0.74-2
Above behavior does not occur with DOSBox 0.74 or 0.74-2 with SDL 1.2.13 or with SDL 1.2.15 (from ScummVM)

How To Ask Questions The Smart Way
Make your games work offline

Reply 7 of 29, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

Qbix,

The private dosbox-46.exe build works fine with SDL 1.2.13 but does show the issue with SDL 1.2.15

How To Ask Questions The Smart Way
Make your games work offline

Reply 8 of 29, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

DosFreak,

Yeah, I kinda assumed it to be this problem, (given my suggestion to try the sdl.dll of 0.74-2). But it is nice to see it confirmed, as it was a guess. I think Dominus knows more about it as well.
Not sure what precisely changed mouse wise, I think you are the most knowledgeable about the sdl changes due to your older windows patches/tries with SDL. Maybe those changes influence things here as well ?

edit: wait, SVN (with SDL 1.2.15) does show it but 0.74-2 ( with SDL 1.2.15) does not ? That is interesting, as I tried backporting as many backend changes from SVN into 0.74-2

Water flows down the stream
How to ask questions the smart way!

Reply 9 of 29, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

Yup Build 46 with SDL 1.2.15 shows the issue. 0.74-2 with SDL 1.2.15 does not. Confirmed just now and verified scaling settings.

If I set SDL_VIDEODRIVER=WINDIB then Build 46 works fine with 1.2.15

How To Ask Questions The Smart Way
Make your games work offline

Reply 10 of 29, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

the windowsize of the dosbox window is the same in both cases (just to make sure that not some highdpiscaling flag is set for the dosbox exe in the register) ?
Can you confirm that both dosbox windows have the exact same size ? (as that was a problem I once had while testing some of the opengl scaling code)

Water flows down the stream
How to ask questions the smart way!

Reply 11 of 29, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

Using default dosbox.conf settings but deleted them all to verify.
Also using SDL_VIDEODRIVER=WINDIB worked with my static builds (that are using SDL 1.2.15).

When I compile SDL 1.2.15 for my builds I don't use the sdl-win32.diff included with DOSBox although I do set the FIXME SDL_HWSURFACE

How To Ask Questions The Smart Way
Make your games work offline

Reply 12 of 29, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
Qbix wrote:

the windowsize of the dosbox window is the same in both cases (just to make sure that not some highdpiscaling flag is set for the dosbox exe in the register) ?
Can you confirm that both dosbox windows have the exact same size ? (as that was a problem I once had while testing some of the opengl scaling code)

NO, they are not, in raw screen pixel term.
With display scaling at 100% (no scaling), if DOSBox starts a 640x480 game, then it will occupy a 640x480 window on screen.
With display scaling at 125%, if DOSBox starts a 640x480 game, the OS will scale and become 800x600 window on screen.

I thought you should have known that from the code in sdlmain.cpp:1267.

#if SDL_VERSION_ATLEAST(1, 2, 10)
#ifdef WIN32
const SDL_VideoInfo* vidinfo = SDL_GetVideoInfo();
if (vidinfo) {
int sdl_w = vidinfo->current_w;
int sdl_h = vidinfo->current_h;
int win_w = GetSystemMetrics(SM_CXSCREEN);
int win_h = GetSystemMetrics(SM_CYSCREEN);
if (sdl_w != win_w && sdl_h != win_h)
LOG_MSG("Windows dpi/blurry apps scaling detected! The screen might be too large or not\n"
"show properly, please see the DOSBox options file (fullresolution) for details.\n");
}
#else

The screenshot for DOSBox side-by-side, with Scaling 125% (left) and No Scaling (right) on 2560x1440 display with 125% scaling. DOSBox WIN32 used for No Scaling representation.

DOSBox_scaling.png
Filename
DOSBox_scaling.png
File size
138.99 KiB
Views
2758 views
File license
Fair use/fair dealing exception

Reply 13 of 29, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

you misunderstood my question, I meant between the working 0.74-2 and the non-working dosbox-46 build with SDL 1.2.15

Water flows down the stream
How to ask questions the smart way!

Reply 14 of 29, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

I was referring to to the window size in the conf in the previous post, attached is a pic showing dosbox 0.74-2(left) and build 46 (right)
You can also see the cursor trapped in the bottom right-hand side of the window in the right pic.

When WINDIB is set the window size is still the same but the mouse works properly.

Hmm, think including freedos edit with DOSBox might be good for troubleshooting purposes since having to do alot of that lately. heh

Only 73 more posts!

Attachments

  • pic.PNG
    Filename
    pic.PNG
    File size
    180.69 KiB
    Views
    2745 views
    File license
    Fair use/fair dealing exception

How To Ask Questions The Smart Way
Make your games work offline

Reply 15 of 29, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
DosFreak wrote:

When WINDIB is set the window size is still the same but the mouse works properly.

That didn't work for me for my WIN64 build. I still have the same mouse cursor malfunction with SDL_VIDEODRIVER=windib.

BTW, how did you get Display Scaling applied for WIN32 build?

Reply 16 of 29, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

I downloaded DOSBox 0.74-2 and run it with its SDL.dll and SDL_net.dll with default conf file. It did not get Display Scaling applied (as expected for WIN32), hence mouse cursor would behave normally. I am not convinced that 0.74-2 does not have the issue until someone come up with the solution to get Display Scaling applied on WIN32.

Reply 17 of 29, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

Qbix private SVN build and my build is 32bit and show the issue you describe.
Have you tried your build with SDL 1.2.13?
Are your 32bit and 64bit builds using the same DOSBox code? Mabye one is 0.74-2 and the other SVN?

How To Ask Questions The Smart Way
Make your games work offline

Reply 18 of 29, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
DosFreak wrote:

Have you tried your build with SDL 1.2.13?

No. I don't have to build SDL on MSYS2/mingw-w64 environment. I simply installed SDL-1.2.15 from its packaging system.

DosFreak wrote:

Are your 32bit and 64bit builds using the same DOSBox code? Mabye one is 0.74-2 and the other SVN?

Both builds were built from the same source at SVN r4168.

I am curious to know how your WIN32 build was built to have display scaling in effect. Are you running on 32-bit or 64-bit Windows 10?

Reply 19 of 29, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

Any progress or update on this? Checking DOSBox SVN history since r4168 does not seem to have any commit related to this. I thought QBix or Dosfreak were able to reproduce the issue, any debugging going on?