macOS Catalina: Only bottom left quarter of the screen is used by the game

[tomkidd]

When running ioquake3 on macOS 10.15 Catalina, after having compiled from the latest source on the command line via Makefile, the resulting window only features the game in the lower left quadrant of the screen and the other 3/4 of the screen is black.

This is launching with just the most standard, vanilla, baseq3 available. No mods, just double-clicking on ioquake3.app under the resulting release-darwin-x86_64.

It's also happening in a build I did of yquake2, as well as another, non-SDL port of Quake II, so I don't think it's related to SDL but it may be related to either OpenGL or just how graphics in general work now but in any event it's not just ioquake3 alone.

I'm using a MacBook Pro Retina, mid-2014 model, with an Nvidia GeForce GT 750M.

The craziest part though is a version of ioquake3 I built before the Catalina upgrade works fine. So it's as if the 10.15 version of the macOS SDK has something to do with it.

Were I to guess I'd say it has something to do with the Retina display and maybe a change in how Catalina calculates screen sizes or something but I've not had luck figuring out what/where that is.

I do plan on digging in to it and seeing if I can figure it out but I thought I'd open an issue just in case someone sees it and can figure it out quicker than I can.

[NuclearMonster]

I would assume you’ve tried doubling (or whatever it takes to get to desktop retina) the custom resolution

[bttd]

I have the same issue on mbp 2017

[icculus]

Add this to the bottom of ioquake3.app/Contents/Info.plist, right above the "" line:

<key>NSHighResolutionCapable</key>
<false/>

You might have to copy (not move) the app to a different name to get Launch Services to notice the change, and then nuke the original and copy it back. This might be optional.

This fixes the problem. I assume for things built with Xcode 11 on Catalina, NSHighResolutionCapable now defaults to true, when it hasn't before. What this flag does is say "my app wants all available pixels at full resolution, not the virtual pixels of what my desktop is scaled to." The end result is we ask for a fullscreen 800x600 window (or whatever), but are ending up with 1600x1200 pixels (or whatever) in the GL context. Then the glViewport(0,0,800,600) call makes it use a quarter of the available space.

Longer term, we can fix this in ioquake3 by setting glViewport to the sizes reported by SDL_GL_GetDrawableSize(), which tells you the size of the window in retina pixels instead of the scaled pixel count that we use for creating the window, but there's a lot of code to sort through that assumes these two pixel counts match 1:1.

Longer longer term: we should render to an FBO at exactly the size we want, use SDL_WINDOW_FULLSCREEN_DESKTOP, and framebuffer_blit to scale/letterbox the final result on the actual window framebuffer.

--ryan.

[dmitrydyomin]

Hi, my experience is slightly different:
15-inch MBP
r_customwidth 2880
r_customheight 1800
r_mode -1

macOS 10.14: Ok
macOS 10.15: Top half of the screen is black, bottom half shows top half of the image. So the image is moved half way down.

I've changed the resolution to 1440×900 as a workaround, works fine.

[tomkidd]

@rcgordon yup, that fixes it. In the other games I mentioned too. I'll try to the build scripts this evening.

[diegoulloao]

Add this to the bottom of ioquake3.app/Contents/Info.plist, right above the "" line:

<key>NSHighResolutionCapable</key>
<false/>

@rcgordon I integrate your solution to my ioquake-mac-install repository, a repository that pretends be an unified simply way to install ioquake3 on macOS (catalina compatible).

I'm working on it and it couldn't be possible without you.
Do you mind add to you as contributor of this project?

Thanks for all!

[icculus]

Do you mind add to you as contributor of this project?

I don't mind.

[bruvzg]

Some info from the same issue in the Godot engine. You can disable HiDPI support from the code by calling [window_content_view setWantsBestResolutionOpenGLSurface:NO];, it might be useful if you want to have ability to switch HiDPI support on and off in runtime instead of disabling it permanently by setting NSHighResolutionCapable flag.

[zturtleman]

Looks like it is fixed for SDL 2.0.12 using the same method as Godot engine. https://hg.libsdl.org/SDL/rev/46b094f7d20e

[icculus]

When we move to SDL 2.0.12 (still in progress!) then we should definitely remove this from the Info.plist, as we'll want to eventually handle this better in the ioQuake3 codebase itself, too, and that'll cause issues, but I think that should be a different bug report at a later time. For now, the Info.plist change is the correct immediate solution.

[mhoran]

I'm also seeing this on Debian Buster (Lenovo X1 Carbon with Intel graphics.) I presume the "longer term" and "longer longer term" changes mentioned in #422 (comment) will apply to Linux as well, but in the interim, there seems to be no workaround. I'm fine running in a window for now, but with the poor performance of Intel graphics, running at a lower resolution scaled up to fullscreen would be preferred.

Meta comment: should I open a separate issue for Linux specifically, or can that be tracked here as well?

[Calinou]

@mhoran Quake3e has r_render* cvars you can use to adjust the rendering resolution. You could try that source port in the meantime. Enter the commands below in the console:

// Use 4 instead of 2 for linear filtering (blurrier).
r_renderScale 2
r_renderwidth 1280
r_renderHeight 720
vid_restart

Note: This breaks if antialiasing is forced in the NVIDIA control panel. (This note is only relevant for NVIDIA graphics anyway.)

[mhoran]

Thanks for the heads up, @Calinou. I may check that port out.

After further investigation I believe I may be hitting a separate issue that is likely Linux specific. It seems to have something to do with multi-head.

I'll do some more digging and potentially open another issue.

[ensiform]

Quake3e doesn't support Mac and is unlikely to without a Mac developer

[numacanedo]

I'm having the same issue described by @dmitrydyomin, the NSHighResolutionCapable fix didn't work for me.

Is there something else I could try?

#422 (comment)

[RichardKirk]

I had this problem with a GLUT task (old GLUT, not freeglut) run from a terminal. This has no obvious way of setting NSHighResolutionCapable. However, I managed to fix this by calling the glut reshape function just after glutShowWindow(). It also has to actually reshape the window - if it is already that size it won't work.

The text comes out half sized, but double spaced. I will post again if I can figure that out.

[RichardKirk]

Here's the other half of my fix.

Background: I have a GLUT job that I run from a terminal. I have used and fiddled with for the last 20 years. For various reasons I am stuck with the original GLUT. This stopped looking right with Catalina. I have not got a practical way to set NSHighResolutionCapable.

In the last post I had to force an actual image resize to stop the drawing in the bottom left quadrant. The text now was coming out looking small, but with the right line spacing so...

int i, xStart=10, yStart=height-10, lineStep=13;
void** font=GLUT_BITMAP_8_BY_13;

#ifdef DARWIN
// Get Retina scale
int v[4];
glRasterPos2i(16, 16);
glGetIntegerv(GL_CURRENT_RASTER_POSITION, v);
if (v[0] > 24) {
  font=GLUT_BITMAP_9_BY_15;
  lineStep = 10;
}
#endif

On my machine, if you set the cursor position as 16,16, glGetIntegerv gets back 32,32. Here DARWIN is a compiler flag which is set if I am compiling on a Mac, so you will need your own flag for that. Here I use a bigger font (not much) and a bigger line spacing when you correct for the scaling.

I am working at home, so I have tried this on the one machine only. I think it has to work for every if the old GLUTworks at all but YMMV. Please post if you find problems.