Skip to content
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

Mac OS X OpenGL fullscreen mispositioning with nonstandard resolutions. #297

Closed
SDLBugzilla opened this issue Feb 10, 2021 · 0 comments
Closed
Labels
wontfix This will not be worked on

Comments

@SDLBugzilla
Copy link
Collaborator

This bug report was migrated from our old Bugzilla tracker.

Reported in version: HG 1.2
Reported for operating system, platform: Mac OS X (All), PowerPC

Comments on the original bug report:

On 2007-03-31 20:24:29 +0000, Ryan C. Gordon wrote:

Date: Fri, 30 Mar 2007 17:38:10 +0200
From: "Rhythmic Fistman"
To: sdl@libsdl.org
Subject: [SDL] opengl fullscreen bug

P.S. On osx 10.4.8 with SDL 1.2.11 when you use set both the SDL_FULLSCREEN
and SDL_OPENGL flags when calling SDL_SetVideoMode, the non supported
resolution/letterboxing/display window centred on black code doesn't work right:
the display window seems to appear at a random on location (not the centre).

Is this a bug? Or is it up to me to position the window in the case? Not sure
how I'd do that if I don't know where the output will be... If it's a bug, it's
actually not that bad, because if you are using fullscreen and opengl, it's not
that hard to choose a supported resolution and then scale up.

Anyway,
RF.

On 2007-06-02 13:59:01 +0000, Ryan C. Gordon wrote:

Bumping a bunch of bugs to Priority 1 for consideration for the 1.2.12 release.

--ryan.

On 2007-06-15 06:59:00 +0000, Ryan C. Gordon wrote:

Okay, I looked into this...this isn't really a Mac bug.

Let's say you call SDL_SetVideoMode(100, 100, 0, SDL_FULLSCREEN | SDL_OPENGL).

What's happening is that the higher level SDL_SetVideoMode() queries if the quartz driver can set the display to 100x100xfullscreen, using SDL_GetVideoMode() through to SDL_VideoModeOK() through to SDL_ListModes(), and finds it can't.

At this point, the X11 driver would say the same thing, but it has set "device->handles_any_size = 1;" in X11_CreateDevice(), which causes SDL_VideoModeOK() to see if there's anything bigger than 100x100 that we can center in, and decides everything is good to go, so SDL_GetVideoMode() lets us pass 100x100xfullscreen to the x11 driver, which does the right thing with centering.

The quartz driver doesn't have handles_any_size set, so SDL_GetVideoMode() picks the closest resolution and adjusts to it...the quartz driver gets 640x480xfullscreen (or whatever) passed to it instead and doesn't know the app ever wanted 100x100.

If you remove the handles_any_size flag from the x11 driver on Linux, it'll behave just like this bug.

Mac OS X doesn't appear to have a way to center the GL context in the middle of the screen (we're using CGLSetFullScreen(), but there isn't a way to say "use part of this display for the context" ... I guess that's what glViewport() is for, but we can't control at that level).. I guess we could create a second window at the right size over a black one, but I don't think it's worth it, since 2D rendering and windowed OpenGL does the right thing here, and GL apps should be able to scale anyhow...this bug has been present for the entire time the quartz driver has been in use, and no one noticed until recently.

However, SDL_GetVideoSurface()->w and ->h is still reporting 100x100 even though the GL context thinks it's 640x480...arguably this is a bug in SDL (and if we can't fix the quartz driver, there's no way for an app to recover here with the wrong information).

So that's all the rambling details. I'm not really sure what to do with this, so I'm tossing it to Sam. It might just be a WONTFIX (or pushed back from 1.2.12), but that's your call.

--ryan.

On 2007-07-04 15:02:33 +0000, Sam Lantinga wrote:

Well X11 can handle any resolution because it has a child window that can be centered in the fullscreen window and is the one actually used for graphics.

Mac OS X doesn't have the same luxury right now and it's probably not worth implementing in 1.2 at this point.

You're right that 2D handles it okay because it can offset the drawing and use pitch to pretend it's smaller, but the way OpenGL does that is by using a viewport. The only way to handle it would be to intercept the viewport calls and transform them. I don't think that's really an option here.

On 2011-12-29 01:19:17 +0000, Sam Lantinga wrote:

*** Bug 979 has been marked as a duplicate of this bug. ***

@SDLBugzilla SDLBugzilla added bug wontfix This will not be worked on labels Feb 10, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

1 participant