-
Notifications
You must be signed in to change notification settings - Fork 81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OpenGL severe display problem on macOS 11 Big Sur #839
Comments
in the repository of DOSBox-x there is a fix for this, I think at joncampbell123/dosbox-x@0c87b06#diff-652a270a42d971e3094d3410653821f6d4dd312cc006a9ac3e101b0fa64baee9 but as there has been more added to the code, it doesn't apply and fix it right away. |
AFAICS, that patch requires applying joncampbell123/dosbox-x@c924e71 first. |
The two patches combined and applies-cleanly-against-current-git diff --git a/src/video/quartz/SDL_QuartzVideo.m b/src/video/quartz/SDL_QuartzVideo.m
index 6e71fbe..1228bfb 100644
--- a/src/video/quartz/SDL_QuartzVideo.m
+++ b/src/video/quartz/SDL_QuartzVideo.m
@@ -1078,6 +1078,18 @@ static SDL_Surface* QZ_SetVideoWindowed (_THIS, SDL_Surface *current, int width,
window_view = [ [ NSView alloc ] initWithFrame:contentRect ];
[ window_view setAutoresizingMask: NSViewWidthSizable | NSViewHeightSizable ];
+
+ NSRect contentRectOrig = NSMakeRect (0, 0, width, height);
+
+#if MAC_OS_X_VERSION_MAX_ALLOWED >= 101500
+ /* OpenGL in Catalina apparently wants to match pixels on Retina displays. Without this the OpenGL
+ display will only use 1/4th the display in the lower left corner. This seems to be an API issue
+ with XCode as binaries previously compiled on Mojave don't have this issue on Catalina. */
+ contentRectOrig = [ window_view convertRectFromBacking:contentRectOrig ];
+#endif
+
+ [ window_view setBoundsSize: contentRectOrig.size ];
+
[ [ qz_window contentView ] addSubview:window_view ];
[ gl_context setView: window_view ];
[ window_view release ]; |
Thanks. |
This is probably correct, please apply. (Usual disclaimer applies, @DominusExult: please move to SDL2 or at least sdl12-compat and let's figure out how to make that happen if something is preventing either solution!). But also: we ran into this in ioquake3 and I believe the fix we ended up with was calling glViewport() with the results of SDL_GL_GetDrawableSize(). Obviously that fix doesn't apply to SDL 1.2, where SDL_GL_GetDrawableSize doesn't exist, but I'm saying this out loud to ponder if SDL2 also should have gotten a similar fix internally. It would need some research. |
I'm just the build maintainer of DOSBox and I am hoping that the main dev makes the plunge soon :) |
It's made a lot of improvements recently! If you make the plunge, I won't be offended if you come directly to me with issues. |
Patch applied as 89fc1b1 |
Something I "just now" realized something is still wrong there. (btw. this works correctly with SDL12compat) |
Re-opening |
@icculus : Any ideas? |
I can't think of anything obvious right now. I'd have to look more deeply. |
Yes please :) |
It's all so very interesting this bug... I wonder if @joncampbell123 has this already fixed in his fork of SDL12 |
As you can see by my mentions in Dosbox-X issues, there is something bad going on that also affects SDL2 as @icculus hinted at here in an earlier comment. |
It is very obvious for me. |
Does this happen when using sdl12-compat? |
(Sorry for the late reply, I just noticed there was exactly one open bug on the 1.2 repo)
We made fixes for HighDPI stuff since then. :) But yeah, SDL 1.2 isn't highdpi aware at all. The best bet, if this is still a going concern, is to move to sdl12-compat, which as far as I know works with DosBox-X, and gets you some useful improvements, like moving software rendering to the GPU, etc. |
very late reply, sorry. This does not happen with current sdl12-compat and I've now changed my whole snapshot builds to only use sdl12-compat and be done with it :) |
Yeah, I'm inclined to say this should be closed with no fix planned and just tell people to use sdl12-compat, as 1.2 is going to continue to bitrot across all platforms as time goes on. |
…g Sur Issue, as reported by Dominik Reichardt: "SDL 1.2x apps compiled against SDK 10.15 or SDK 11.x have severe display problems when started on macOS 11. All is fine on macOS < 11.x, or when compiled against SDK 10.14. The window is as big as it should be, but the actual video display is in the lower left corner as if it only renders to the lower left quarter of the screen. Observed with DOSBox, but reproduced with SDL's testgl program." Fix extracted from two DOSBox-X commits authored by Jonathan Campbell: joncampbell123/dosbox-x@c924e71 joncampbell123/dosbox-x@0c87b06 Closes: libsdl-org#839
SDL 1.2x apps compiled against SDK 10.15 or SDK 11.x have severe display problems when started on macOS 11. All is fine on macOS < 11.x or when compiled against SDK 10.14.
The window is as big as it should be but the actual video display is in the lower left corner, as if it only renders to the lower left quarter of the screen. Observed with DOSBox but reproduced with SDL's testgl program.
It seems that it doesn't matter against which SDK you compiled SDL 1.2x.
Tested with current git and also 5d44141 (as the next commit 718b76b added some macOS OpenGL fixes, I thought I'd try the commit before).
Screenshot of testgl compiled against SDK 10.15 on macOS 11
![testgl_SDK_1015](https://user-images.githubusercontent.com/3313896/110653724-ccd14180-81bd-11eb-9d89-cde7f63d8ae6.png)
Screenshot of testgl compiled against SDK 10.14 on macOS 11
![testgl_SDK_1014](https://user-images.githubusercontent.com/3313896/110653913-f8542c00-81bd-11eb-9386-107ce9aca785.png)
Edit: with testdyngl, you can see that it really renders to the lower left quarter of the window
![testdyngl](https://user-images.githubusercontent.com/3313896/110656580-5da91c80-81c0-11eb-937f-56f145f11a3b.png)
The text was updated successfully, but these errors were encountered: