search

joncampbell123 / dosbox-x

DOSBox-X fork of the DOSBox project
GNU General Public License v2.0
2.81k stars 383 forks source link

Scaling issues with SDL2 version on macOS 11.1 (ARM) #2180

Open hiatsu0 opened 3 years ago

hiatsu0 commented 3 years ago

The SDL2 version seems to have some scaling issues where the content is most of the time scaled to approx. 1/4 size, on the bottom-left corner of the window. SDL1 version works just fine. The scaling does seem to correct itself if the window is moved a bit by dragging from the top bar but any change to the content, such as starting a game usually drops it back to quarter scale.

Tried changing Video > Scaler type and Video > Output between Surface / OpenGL without any effect.

To Reproduce

  1. Start dosbox-x SDL2 version (content appears on bottom-left corner)
  2. Drag the window from the top bar (content usually scales to full window)

Screenshots:

Default start, everything is about 1/4 scale at the bottom-left corner: https://drive.google.com/file/d/13PmWjzsxezJ7MxI1f1DsJ6ywEDuR2hJF/view?usp=sharing

After moving the window from top bar a little, it scales to full window: https://drive.google.com/file/d/1FSTIzP9Qe9VYxTKY5e1NsXF4U7Se4mzN/view?usp=sharing

Setting menus can only be used with keyboard as the button locations don't match what is seen. By blindly clicking on approximate location where they would be in full window scaling, it is possible to click them. https://drive.google.com/file/d/1rjWw3DnemNcMctfckIiCNzTAl_ew5dG-/view?usp=sharing

Same as above but with the mapper: https://drive.google.com/file/d/1C9kL87t4UIgfK1CMuKZYA8qEXUHJIVw8/view?usp=sharing

Sometimes previous text remains visible when a game is started and it scales down to 1/4 size: https://drive.google.com/file/d/1n5cgenkPAdW40dDQ2pmAZGMCKYPsFBYG/view?usp=sharing

And also reverse happens when quitting a program: https://drive.google.com/file/d/1PPT0_GnaE_06gbRVNjXU8rVr4L59kFAk/view?usp=sharing

Environment:

Wengier commented 3 years ago

Thanks for reporting the issues with scaling! While I was not able to reproduce the exact same problems with macOS SDL2 build on my macOS x86-64 VM, I can confirm there are bugs when resizing window with e.g. the OpenGL output on macOS SDL2 build. On the other hand, they certainly work better on macOS SDL1 build or Windows SDL2 build.

dixius99 commented 3 years ago

I'm seeing the same issue with 0.83.10 on my Intel Mac running Big Sur. @Wengier has fixed this a few times with previous builds when I mentioned it on Reddit. Not sure exactly how...

Wengier commented 3 years ago

@dixius99 Thanks for reporting here. I would like to know which macOS package you downloaded and used for DOSBox-X 0.83.10: dosbox-x-macosx-0.83.10-bin64.zip or dosbox-x-macosx-x86_64-20210131230837.zip? If you used one can you try the other too?

dixius99 commented 3 years ago

@Wengier I've tried both and unfortunately, it's the same issue with both.

Wengier commented 3 years ago

@dixius99 Interesting. Can you try set "dpi aware=false"/"dpi aware=true" in [dosbox] section of the configuration and see if it helps to solve the problem?

dixius99 commented 3 years ago

@Wengier It does not change anything for 0.83.10.

However, if I make the change in my config and try to launch. 0.83.9, "dpi aware=true" results in the same issue of the contents scaling into the bottom left corner of the screen. "dpi aware = false" and "dpi aware = auto" the default both give me an image that scales to the full window.

As you can probably guess, the image when "dpi aware" is set to false is blocky (as I would expect for DOSbox), while, after moving my window around a little as @hiatsu0 mentions, the image is smoother/blended.

joncampbell123 commented 3 years ago

I'm aware of this issue on my test systems, though I do not yet have a fix.

This happens on both ARM and Intel builds on Mac OS X.

Moving the window magically fixes it somehow, until the window is resized again.

dixius99 commented 2 years ago

I just installed the latest SDL2 version (0.83.20), and I do not see the resolution issue any more. @joncampbell123 and @Wengier : can we consider this one fixed?

Wengier commented 2 years ago

@dixius99 I think this issue was caused by some external library rather by DOSBox-X itself. It is perhaps fixed there.

dixius99 commented 2 years ago

@Wengier hmm... could be.

Although, I can confirm that I still see the issue with 0.83.19, but not 0.83.20. I thought that would indicate it is something within Dosbox-X itself.

EDIT: Upon further testing, the issue still seems to happen occasionally in windowed mode, and frequently in fullscreen, so I guess it isn't resolved anyway.