VOGONS


Reply 40 of 67, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
Dominus wrote on 2021-07-18, 12:08:

Can you elaborate how that problem manifests itself? I don't quite understand...

Step #1 Get a game called Dune 2: Building of a Dynasty (1992) by Westwood Studio
Step #2 Use an expensive 27" 4K/8K panel (... quietly weep) so *Display Scaling* becomes inevitable unless one was genetically modified to have the eye sight of eagle. Or, use a MacBook with retina screen. (... quietly weep)
Step #3 Play the game in *windowed*. Scale the window however one likes, with windowresolution or scaler={whatever}3x
Step #4 Have fun with the Game!

Dominus wrote on 2021-07-18, 12:08:

IMO, my OpenGL fix is better if the hardcoded scaling value can be obtained programmatically.

but it's already in SDL git so this needs to be fixed instead of doing it per program, IMO. Maybe voice in in the bug report https://github.com/libsdl-org/SDL-1.2/issues/839 ?

That's why it's called SDL git. 😉 There is no per-program fix in DOSBox. It is an inherent problem when one just scaled display without mouse motion in-sync. Apparently, DOSBox already has some logics to keep display and mouse motion in-sync with its own scaling when SDL didn't mess up. That's why my OpenGL fix worked. If SDL is doing transparent scaling, then it must deal with both display and mouse motion.

Reply 41 of 67, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Per program fix was meant: per program that uses SDL 1.2x

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 42 of 67, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
Dominus wrote on 2021-07-18, 19:03:

Per program fix was meant: per program that uses SDL 1.2x

No, when SDL1.2 didn't mess with display scaling. So all SDL1.2 programs are really DPI-unaware. They just become tiny rectangle for rich people using HiDPI display.

I am on Liberachat IRC. 😉

Reply 43 of 67, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
Dominus wrote on 2021-07-18, 19:03:

Per program fix was meant: per program that uses SDL 1.2x

OK, now I understand the context of per program fix. Yes, you're right, every program that uses SDL1.2 has to shrink the window size or else for SDL_OPENGL they will have 1/4th of the rendered display at lower-left of the window. All SDL1.2 programs have this problem now with retina display, unless they go fullscreen or they don't need a mouse.

So the correct fix for SDL1.2 is to do the same as my OpenGL fix, to shrink NSWindow width/height to match the OpenGL display at real screen pixels. This is the easier fix without having to hack SDL1.2 to have the same mouse motion warping as in SDL2.

Reply 44 of 67, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

It looked like DOSBox already managed its mouse motion, so just need to make sure sdl.clip.w and sdl.clip.h have the correct size corresponding to mouse motion in real screen pixels. Incidentally, sdl.clip.w and sdl.clip.h are also used for glViewport() so having them in the correct size as real screen pixels then uses OpenGL to scale the display. I updated patch v2 and I think this is the correct fix. The SDL fix isn't necessary, everyone should be using the pristine HomeBrew bottle for SDL.

The scaling ratio is still hardcoded for macOS. But it is a universal solution dealing with display scaling. SDL1.2 will always provide mouse motion in real screen pixels and I probably know by now how to fix this issue I reported in 2018 through native Windows APIs if I can reproduce the build that honors Windows 10 display scaling. Does macOS have C/C++ binding APIs for querying display scaling? Oh, not Objective-C please! 🤣

If anything that SDL1.2 could be hacked to improve, then an API for querying display scaling is all that is required. All SDL1.2 apps are essentially broken for not being DPI-aware.

Looking at how glViewport() scaled the display for DOSBox, I have finally discovered the solution to scale Kekko's Voodoo chip emulation. 😁 Yahoo! 😁

Reply 45 of 67, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Problem is that this will eventually be added to brew or macports and thus it will break Dosbox again. Fix it in the source and not in Dosbox 😉
Have you tried SDL 1.2 git or just applied that patch?

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 46 of 67, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
Dominus wrote on 2021-07-19, 07:55:

Problem is that this will eventually be added to brew or macports and thus it will break Dosbox again. Fix it in the source and not in Dosbox 😉
Have you tried SDL 1.2 git or just applied that patch?

Do you mean that SDL 1.2 git already have both the display scaling and mouse motion managed properly on macOS?
Have you tried anything that requires a mouse pointer on your DOSBox without going fullscreen?

I just cherry-picked the patch and modified brew formula to add it. It didn't work for anything that requires a mouse pointer.

SDL1.2 also completely screwed up Windows display scaling. The mouse motion event is broken totally with display scaling, so there is no hope for Windows 10 to use DOSBox with OS display scaling. The data in motion {x, y, x-rel, y-rel} was totally wrong.

Reply 47 of 67, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

I have not yet tested anything recently, though I'm pretty sure I have played a bit of Ultima VII since march with this git on my intel Big Sur machine (and the wrong display was on intel Big Sur as well) and I have no memory of that being problematic.
If you obly cherry pick the macOS fixes you are bound to miss other patches as well. Mouse stuff is not necessarily labeled with macOS.

Edit: ok, now tested and indeed there is something wrong 😀 The clicks do not register in the DOSBox window but the windows below. That should be something to report to the SDL people.
Edit2: with SDL12compat this works 😀

Edit3: you don't need any scaling to see this (windowres original, scaler none, oglshader none)

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 48 of 67, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

Thanks, at least I knew the problem well since 2018 😉 when I quietly weep after getting a 24" 2K panel.

At least the mouse motion packet from SDL1.2 is still returning sane data in {x, y, x-rel, y-rel} for macOS, unlike Windows 10, they are just in real screen pixels instead of the width/height that the app passed into SDL_SetVideoMode(). I guess the folks at SDL1.2 were sick of all those DPI-awareness issues for SDL1.2. For DOSBox, there is an easy fix without resorting to SDL12compat but have to figure out how to obtain the scaling ratio through macOS SDK C/C++ binding APIs. If DOSBox devs don't mind doing that in Objective-C, then it is fine, too. I just don't know how.

*Sigh*... SDL1.2 really must die. 😀

Reply 49 of 67, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
Dominus wrote on 2021-07-19, 07:55:

Problem is that this will eventually be added to brew or macports and thus it will break Dosbox again. Fix it in the source and not in Dosbox 😉

I don't believe that this will be added. Whether it was just coincidence or the issue was well understood, SDL1.2 is just not being DPI-aware. That's why there is SDL2. It would just be a never-ending argument on one's ideology of who should fix what.

"I am calling SDL_SetVideoMode(640, 480). How the hell am I getting beyond {0, 639} for {x}, beyond {0, 479} for {y} and {x-rel, y-rel} that are insanely huge and propel the pointer location outside the rect clip? There is nothing wrong in my codes, I am not fixing other's problems." -- (DOSBox 6: 6-66)

"I am just the middleman that makes every developers' life easy by forwarding that same (640, 480) to their platform specific native window APIs and returning the same data {x, y, x-rel, y-rel} from native pointer events. There is nothing wrong in what I am doing. I have no plan to marshal data to & from native platform APIs." -- (SDL1.2 9: 9-99)

It's a stalemate. 🤣

Last edited by kjliew on 2021-07-20, 01:47. Edited 1 time in total.

Reply 50 of 67, by Bruninho

User metadata
Rank Oldbie
Rank
Oldbie

To be fair, SDL 1.2 shouldn'even be updated, let it die, it's already deprecated. Focus should be on making DOSBox features work fullscreen with SDL2... ...AND... fix the damn full yellow tone screen that SDL2 DOSBox builds have when running Windows, I haven't even tested a game because... I couldn't stand the yellow screen.

DOSBox-X SDL1.2 build is working here even without SDL1.2 installed. I have only SDL2.

"Design isn't just what it looks like and feels like. Design is how it works."
JOBS, Steve.
READ: Right to Repair sucks and is illegal!

Reply 51 of 67, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Well, the only thing that broke it on macOS was something Apple did to their OpenGl in SDK 10.15 and newer. And since SDL is the middleman they are supposed to fix it and I'm pretty sure they will. Since it is based on a fix by DOSBox-X' fork of SDL12, the next thing to check is whether that exhibits the same problem. 🤷‍♂️
I really think that fixing it in DOSBox is a bad bandaid, when SDL is the better one.
The cure is of course SDL2.

And brew will add this patch because it superficially fixes the problem.

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 52 of 67, by Bruninho

User metadata
Rank Oldbie
Rank
Oldbie

But about OpenGL I have been saying that Apples OpenGL 2.1 can be overridden and upgraded to 4.1; Just install freeglut, glew and glfw through brew/macports/whatever and make sure Dosbox/Sdl2/whatever your app is finds it. I can’t honestly understand what is the real problem here.

I have installed all three packages, and ran a test app that reported the right OpenGL version.

"Design isn't just what it looks like and feels like. Design is how it works."
JOBS, Steve.
READ: Right to Repair sucks and is illegal!

Reply 53 of 67, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

I came to realize that Apple indeed has smart brass in charge of the OpenGL SDK or just another coincidence. Unlike macOS, OpenGL in Windows 10 is subjected to display scaling so the GL drawable size and pointer clipping will be out-of-sync. But Windows 10 allows display scaling to be turned off globally or for specific apps, macOS doesn't. If brew added the SDL git fix, then it broke the apps that assume the same windowing clipping can be used for drawable and pointer, and DOSBox happens to be one of them.

And there is already SDL2. It doesn't make sense to add the patch which only solves half the problem. I tend to agree that it is messy to marshal data to & from native platform APIs, otherwise It would be easier just to shrink the window decoration in QZ_SetVideoWindowed() and everything else are intact as they used to.

So create jobs, let there be lots of jobs for software developers and have everyone moved to SDL2. 😉

For GPL freebies, well just quietly weep ... or let hostile forks outshine the mainline (... quietly weep). 🤣

I am sure there is still a lot of fun for DOSBox devs and for keeping VOGONS alive for all of us. 😉

Reply 54 of 67, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

If brew added the SDL git fix, then it broke the apps that assume the same windowing clipping can be used for drawable and pointer, and DOSBox happens to be one of them.

If they don't add it, it's also broken. I'm pretty sure the only reason they didn't add it is because there are so few SDL 1.2 programs left and no one reported that this is broken on macOS 11.
More the reason for SDL to fix it rather than hoping all the few affected programs fix it.

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 55 of 67, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator
Bruninho wrote on 2021-07-19, 21:58:

But about OpenGL I have been saying that Apples OpenGL 2.1 can be overridden and upgraded to 4.1; Just install freeglut, glew and glfw through brew/macports/whatever and make sure Dosbox/Sdl2/whatever your app is finds it. I can’t honestly understand what is the real problem here.

I have installed all three packages, and ran a test app that reported the right OpenGL version.

I wouldn't want to touch that, let alone figure out how to be able to bundle this.
When you recommend this keep in mind, or better be prepared to answer whether this is something one could easily bundle. If it needs an install of brew or macports, it isn't IMO.
And you don't even know whether this fixes it. You would still need to interface with macOS graphics drivers, right?

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 56 of 67, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
Dominus wrote on 2021-07-19, 22:33:

If brew added the SDL git fix, then it broke the apps that assume the same windowing clipping can be used for drawable and pointer, and DOSBox happens to be one of them.

If they don't add it, it's also broken. I'm pretty sure the only reason they didn't add it is because there are so few SDL 1.2 programs left and no one reported that this is broken on macOS 11.
More the reason for SDL to fix it rather than hoping all the few affected programs fix it.

Even if they add it, it's also still broken, unless someone also puts forward a solution for mouse motion. DOSBox-X's patch only addressed half of the problem and I can understand how the patch looked good if one didn't test with SDL OpenGL apps that require mouse. GitHub issue #839 only focused on the display part. There is no testgl_with_pointer in SDL1.2 test cases.

So then the reason to make one less SDL 1.2 programs would stand out. 😉

Reply 57 of 67, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

DOSBox-X issue #2478 -- look like SDL2 also exhibits the same problem with OpenGL display. This is a stronger evidence that no SDL1.2 should ever pick up the fix, not even SDL2 will fix it for everyone in a transparent way to deal with display scaling. But SDL2 does have APIs to obtain window size vs drawable size. So DOSBox-X now have all the details to the solution of that issue from this thread. And they fixed the same issue for SDL1.2 by bundling the patched up version of SDL1.2, how nice! 🤣 And the patched up SDL1.2 ended up in another DOSBox-X issue #1697.

It seems that SDL2 prefers to have the apps managed DPI-awareness on their own. So then the source of problem is the app, not the middleman.

Well, if there is any good news that I bring to DOSBox devs, then there is no need to go for SDL2. 😉 If there is no way to obtain the scaling factor, then simply make it into configuration option from dosbox.conf.
[sdl]
# dpi_scale: DPI scaling in percentage.
dpi_scale=100

Reply 58 of 67, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
Bruninho wrote on 2021-07-19, 21:23:

To be fair, SDL 1.2 shouldn'even be updated, let it die, it's already deprecated. Focus should be on making DOSBox features work fullscreen with SDL2... ...AND... fix the damn full yellow tone screen that SDL2 DOSBox builds have when running Windows, I haven't even tested a game because... I couldn't stand the yellow screen.

DOSBox-X SDL1.2 build is working here even without SDL1.2 installed. I have only SDL2.

DOSBox-X uses a heavily modified SDL1.2 that includes high DPI awareness in Windows and Mac OS X and a workaround that still works in Big Sur.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 59 of 67, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
TheGreatCodeholio wrote on 2021-07-20, 20:06:

DOSBox-X uses a heavily modified SDL1.2 that includes high DPI awareness in Windows and Mac OS X and a workaround that still works in Big Sur.

You really can't make that claim when DOSBox-X issue #1697 remains opened. And I am also pretty sure that high DPI awareness has never been working for Windows 10. I would love to be proven wrong anyway. 😉