integer scaling on a Mac Retina screen

[mbunkin]

I don't think pixel perfect integer scaling works on my Retina screen. It requires 1600x1200 minimum, my full screen resolution is 2880x1800. Perhaps SDL is not utilising the full Retina resolution.

[Falcury]

It requires 1600x1200 minimum

That is only the case if 4:3 aspect ratio is also enabled.
It may be helpful to have some more details on the problem you are experiencing?

[mbunkin]

The problem is simple, switching on the integer scaling doesn't change the visual appearance. I can send a screenshot, if it helps? I believe it's because the SDL uses the non-Retina resolution of 1440x900. Can I assist somehow? I have this idea of integer scaling myself for several years - with a few black margins 320x200 can be emulated very precisely on my Retina screen. So I'm eager to see it in action.

[Falcury]

Are you running in fullscreen mode then?
In windowed mode, you should notice the difference only when you resize the window (because the default window size 640x400 is already an integer multiple of 320x200).

[mbunkin]

Yes, it's full screen. I made a small screenshot and compared the pixel width. It's either 6 or 8 pixels, never 7 or 5. Which means that SDL is not using the full Retina resolution.

[Falcury]

What version of SDL2 are you on?
Note that SDL_RenderSetIntegerScale is a recent feature, it was introduced in version 2.0.5.

[mbunkin]

I downloaded the latest stable SDLPoP 1.18.1, but I can't see what SDL version is inside. I assumed if it has that option in the menu, it should have the feature?

[NagyD]

but I can't see what SDL version is inside.

Hm, maybe there should be a debugging option to display this somewhere?

I made a small screenshot and compared the pixel width. It's either 6 or 8 pixels, never 7 or 5. Which means that SDL is not using the full Retina resolution.

From what I know, Retina Display automatically upscales the output of Retina-unaware applications to double size; and correspondingly, applications probably see half of the actual resolution.
(source 1) (source 2)
(Documentation by Apple, section "Apps That Aren’t Yet Ready")

There is some documentation about SDL and Retina (high-DPI) in the SDL docs.
This remark seems to be of interest:

On Apple's OS X you must set the NSHighResolutionCapable Info.plist property to YES

In the latest DMG file, this setting is not even present in the Info.plist file.
Maybe you (or someone else) could try adding these lines:

	<key>NSHighResolutionCapable</key>
	<true/>

(I don't have Mac OS X, so I can't test this.)

[Falcury]

Ah. If I remember correctly, I built the bundle in the .dmg file using SDL 2.0.5, so that should be fine.

Maybe you (or someone else) could try adding these lines:

OK, I will try to reproduce the issue (I will need to ask someone who has a Retina machine nicely...), then see if that fixes it.

Hm, there is also the SDL_WINDOW_ALLOW_HIGHDPI window creation flag, described here:
https://wiki.libsdl.org/SDL_CreateWindow

I guess that needs to be set as well.

[mbunkin]

I tried adding NSHighResolutionCapable to Info.plist, it didn't enable Retina support. Let me know what else to try. I'll be delighted to help, as far as my schedule allows.

I would also suggest forcing discrete GPU when using Retina, because on laptops with integrated and discrete GPUs, when switching to Retina mode without forcing discrete GPU first, it can enter a mode with lower physical resolution and larger framebuffer, which effectively shows only a portion of the framebuffer on the screen. I've seen games suffering from it, but it may be simple to work around, I found this article, maybe it will work: https://stackoverflow.com/questions/16823372/forcing-machine-to-use-dedicated-graphics-card#39047129 - seems like just a single line of code.

Let me know how can I assist.

[NagyD]

Let me know what else to try.

You could try adding the flag that Falcury mentioned above.
That is, here in seg009.c, add this new line:

	flags |= SDL_WINDOW_ALLOW_HIGHDPI;

And recompile.

I found this article, maybe it will work: https://stackoverflow.com/questions/16823372/forcing-machine-to-use-dedicated-graphics-card#39047129 - seems like just a single line of code.

It says it's for Windows, and that it might not work on MacOS.

[Falcury]

I attached a test build, can you try it and see if it works?
SDLPoP.macOS.Retina.test.zip

Commit: Falcury@f1f6496

[mbunkin]

I can confirm this build uses Retina resolution and switches on the discrete GPU. It always starts in windowed mode, I can’t tell if there are any problems when it would start in fullscreen. Integer scaling does not change anything (in 4:3), either it doesn’t work, or works always - in either case, the pixel size is greatly improved on Retina screens, which is great, and it’s officially the best looking Prince on a Mac :)

…

On Apr 28, 2018, at 23:18, Falcury ***@***.***> wrote: I attached a test build, can you try it and see if it works? SDLPoP.macOS.Retina.test.zip <https://github.com/NagyD/SDLPoP/files/1958145/SDLPoP.macOS.Retina.test.zip> Commit: ***@***.*** <Falcury@f1f6496> — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#173 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMRDPSgkMkTDPn7eUOzG-HF91BCF8HiJks5ttM6ngaJpZM4TczdZ>.

[Falcury]

It always starts in windowed mode, I can’t tell if there are any problems when it would start in fullscreen.

You could test that by switching on the 'Start fullscreen' setting in the pause menu (Settings -> Visuals), then quitting and restarting the game.

Integer scaling does not change anything (in 4:3), either it doesn’t work, or works always - in either case, the pixel size is greatly improved on Retina screens, which is great, and it’s officially the best looking Prince on a Mac :)

That's good to hear :)
Although it's still strange that the integer scaling doesn't seem to do anything in your case.

[mbunkin]

I tried “start fullscreen” and it works impeccable. Better than quite a few commercial games. It is indeed strange that integer scaling doesn’t work. What would be the expected behaviour, with a resolution of 2880x1800 at 16:9 when the game is set to 4:3? How different it should be from non-integer scaling?

…

On Apr 28, 2018, at 23:58, Falcury ***@***.***> wrote: It always starts in windowed mode, I can’t tell if there are any problems when it would start in fullscreen. You could test that by switching on the 'Start fullscreen' setting in the pause menu (Settings -> Visuals), then quitting and restarting the game. Integer scaling does not change anything (in 4:3), either it doesn’t work, or works always - in either case, the pixel size is greatly improved on Retina screens, which is great, and it’s officially the best looking Prince on a Mac :) That's good to hear :) Although it's still strange that the integer scaling doesn't seem to work in your case. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#173 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMRDPf9J3Eu5Cvyp1p87jCSU068Xtxb7ks5ttNfsgaJpZM4TczdZ>.

[EndeavourAccuracy]

but I can't see what SDL version is inside.

Hm, maybe there should be a debugging option to display this somewhere?

If you put SDL_version verc, verl; in a .h somewhere, you could make Ctrl+c show the version numbers by adding inside the switch(key) of seg000.c this:

    case SDL_SCANCODE_C | WITH_CTRL: // ctrl-c
      SDL_VERSION (&verc);
      SDL_GetVersion (&verl);
      snprintf (sprintf_temp, sizeof (sprintf_temp),
        "SDL COMP v%u.%u.%u LINK v%u.%u.%u",
        verc.major, verc.minor, verc.patch,
        verl.major, verl.minor, verl.patch);
      answer_text = sprintf_temp;
      need_show_text = 1;
      break;

By the way, unrelated, in the master branch, the start-up info screen currently shows up only a fraction of a second, so something probably broke somewhere...

[NagyD]

you could make Ctrl+c show the version numbers

Done: b35b3f3

It is indeed strange that integer scaling doesn’t work.

I figured out what might cause this.
Integer scaling is enabled only if the window size is bigger than the render size: https://github.com/NagyD/SDLPoP/blob/master/src/seg009.c#L2192
(Render size is 320×200 by default and 1600×1200 in 4:3 mode)
Now, the question is, how does SDL measure the window size on high-DPI screens, in points or pixels? (See Apple's docs for the difference between the two.)
Your screen is 2880×1800 pixels but 1440×900 points.
If SDLPoP sees the latter as the size of the fullscreen window, then it won't enable integer scaling in 4:3 mode.

You (or Falcury) could add a debug printout to the source line I linked, to see what is SDLPoP's idea about these two sizes.

with a resolution of 2880x1800 at 16:9

That is 16:10, by the way. :)

[mbunkin]

You must be right. But I’ll add debugging to make sure. I don’t have the source on my machine yet, but I’ll try to build it now. You are right about 16:10 as well :)

…

On Apr 29, 2018, at 18:39, Dávid Nagy ***@***.***> wrote: you could make Ctrl+c show the version numbers Done: b35b3f3 <b35b3f3> It is indeed strange that integer scaling doesn’t work. I figured out what might cause this. Integer scaling is enabled only if the window size is bigger than the render size: https://github.com/NagyD/SDLPoP/blob/master/src/seg009.c#L2192 <https://github.com/NagyD/SDLPoP/blob/master/src/seg009.c#L2192> (Render size is 320×200 by default and 1600×1200 in 4:3 mode) Now, the question is, how does SDL measure the window size on high-DPI screens, in points or pixels? (See Apple's docs <https://developer.apple.com/library/content/documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Explained/Explained.html> for the difference between the two.) Your screen is 2880×1800 pixels but 1440×900 points. If SDLPoP sees the latter as the size of the fullscreen window, then it won't enable integer scaling in 4:3 mode. You (or Falcury) could add a debug printout to the source line I linked, to see what is SDLPoP's idea about these two sizes. with a resolution of 2880x1800 at 16:9 That is 16:10, by the way. :) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#173 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMRDPbJkVIgE1b_pq5gFRTWTAOvYrOo8ks5ttd6VgaJpZM4TczdZ>.

[mbunkin]

I checked and indeed window_width / window_height contain the "points", 1440x900.
Furthermore, trying to set makes_sense to true resulted in screen going black when I switch to integer scaling.

[NagyD]

I checked and indeed window_width / window_height contain the "points", 1440x900.

Indeed, https://wiki.libsdl.org/SDL_GetWindowSize recommends other functions that will return the correct value on a high-DPI screens.

I changed the way I read the window size: abdd7bd

Furthermore, trying to set makes_sense to true resulted in screen going black when I switch to integer scaling.

That happens when the window is smaller than the render size.
Which source did you compile?
On the master branch, SDL_WINDOW_ALLOW_HIGHDPI wasn't enabled.
So I also added that in the commit above.
Please pull the latest source from GIT and try that.
Don't forget the NSHighResolutionCapable in the Info.plist file. (That file is not yet on the master branch.)

[mbunkin]

It works! I just run ‘prince’ from console, so NSHighResolutionCapable is not required for the test. Superb!

…

On Apr 30, 2018, at 09:48, Dávid Nagy ***@***.***> wrote: I checked and indeed window_width / window_height contain the "points", 1440x900. Indeed, https://wiki.libsdl.org/SDL_GetWindowSize <https://wiki.libsdl.org/SDL_GetWindowSize> recommends other functions that will return the correct value on a high-DPI screens. I changed the way I read the window size: abdd7bd <abdd7bd> Furthermore, trying to set makes_sense to true resulted in screen going black when I switch to integer scaling. That happens when the window is smaller than the render size. Which source did you compile? On the master branch, SDL_WINDOW_ALLOW_HIGHDPI wasn't enabled. So I also added that in the commit above. Please pull the latest source from GIT and try that. Don't forget the NSHighResolutionCapable in the Info.plist file. (That file is not yet on the master branch.) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#173 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMRDPafVAoTc3XBZmhlKfAcXiGirmcv8ks5ttrPagaJpZM4TczdZ>.

[NagyD]

It's good to hear that.

Can I close this now?

[mbunkin]

I think so, if it works for me, it’ll work for any Mac user. Thank you very much!

…

On May 1, 2018, at 16:19, Dávid Nagy ***@***.***> wrote: It's good to hear that. Can I close this now? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#173 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMRDPYziB1VABQZCsSOtd_VPQ7hzMTUjks5tuGDEgaJpZM4TczdZ>.