VOGONS

Common searches


Reply 20 of 29, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

I am not sure that I was able to reproduce it.
Think I was still waiting on your testing results with regards to the window size between those 2 builds mentioned earlier.

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

Reply 21 of 29, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

Think Windows 10 1809 enables the "Let Windows try to fix apps so they're not blurry" option and also reduces the blurry apps notifications as well so that needs to be tested too.

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

Reply 23 of 29, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
DosFreak wrote:

Qbix private SVN build and my build is 32bit and show the issue you describe.

I couldn't get my WIN32 build to show the issue, but you guys did with your private SVN build as DosFreak said.

Reply 24 of 29, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

DosFreak is talking both times on his experiences. My private build is public for the beta testers.

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

Reply 25 of 29, by DosFreak

User metadata
Rank l33t++
Rank
l33t++
FulValBot wrote:

That option is not enabled as default;

check it on your system.

Yup, looks like it wasn't for 1809 but the next major build but it still needs to be tested.

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

Reply 26 of 29, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

FILES
Qbix DOSBox SVN from Jan 2019
FreeDOS Edit
http://www.ibiblio.org/pub/micro/pc-stuff/fre … -html/edit.html

SDL 1.2.13 from DOSBox 0.74-2
SDL 1.2.15 from SDL website (version says 1.2.14 but they never changed the version #)
https://www.libsdl.org/release/SDL-1.2.15-win32.zip

1. Right-click desktop ->display settings-Set scaling to 125% or higher
2. Launch dosbox in a window
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.

Tested with Windows 10 1809

As when I tested before it looks like it occurs with SDL 1.2.14 and 1.2.15 with SVN. (Official DOSBox for Windows uses SDL 1.2.13)
DOSBox 0.74-2 does not have this issue with SDL 1.2.14 or 15 due to scaling being disabled for it.

SVN workarounds
Use SDL 1.2.13 which is what the official ver of DOSBox uses
or
Set the sdl_videodriver=windib variable
or
Set compatibility option for High DPI scaling to "Appication". Set dosbox.conf output=Any non-surface and change windowresolution to a higher resolution

Attachments

  • Filename
    DOSBox-test.zip
    File size
    1.97 MiB
    Downloads
    119 downloads
    File license
    Fair use/fair dealing exception

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

Reply 27 of 29, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
DosFreak wrote:

Set compatibility option for High DPI scaling to "Appication". Set dosbox.conf output=Any non-surface and change windowresolution to a higher resolution

This is equivalent to disabled Display Scaling or having Display Scaling at 100%. Without Display Scaling, this is not an issue at all.

Setting SDL_VIDEO_DRIVER=windib does not work on WIN64 DOSBox SVN using SDL-1.2.15 from MSYS2/mingw-64-x86_64 SDL package. I still can't get Display Scaling to be in effect for WIN32 DOSBox using SDL-1.2.15 from MSYS2/mingw-w64-i686 package or my own compiled of SDL-1.2.15 for MinGW.org.

I wonder if this is SDL1.2 issue or DOSBox issue on dealing with mouse pointer position. If this is SDL1.2 issue, then obviously there won't be any update for SDL1.2 anymore so this will never be fixed, unless someone is willing to debug and come up with patch. If this is DOSBox issue, then I hope the devs will get to reproduce it and fix it in the future for the sake of WIN64 build.

Since I also work on QEMU a lot, I can tell that QEMU built with SDL1.2 does not have this issue for both WIN32 and WIN64 build, and Display Scaling is in effect on both versions, including WIN32 versions built with MinGW.org. I knew I could still be wrong, but this fact would lean the issue towards DOSBox handling of captured mouse pointer.

Reply 28 of 29, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

With jmarsh's 64-bit dyn_x86 core on the horizon, native 64-bit build is making a lot of sense now. With native 64-bit, Windows 10 display scaling will be in effective and any point-and-click DOS games will fail. Yes, there is workaround by disabling Windows 10 display scaling and use hardware scaler on the output to size up the rendering.

Still hoping to get an out-of-the-box solution that works with Windows 10 display scaling.

Reply 29 of 29, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

Bumping up the thread. The macOS's look & design artistic on the retina display may have helped to reach a solution for Windows 10 display scaling.

Problem: SDL1.2 mouse motion events always come in real screen pixels for x, x-relative, y and y-relative. DOSBox setups sdl.clip.w & sdl.clip.h based on requested screen mode, for eg. 640x480. At 125% display scaling, the real screen size is 800x600. HandleMouseMotion() becomes erroneous.