Does SDL_GetWindowSize() work properly for iPhone?

Testing on the iPhone simulator with retina display, if I create an SDL window with 640x960 resolution, and then call SDL_GetWindowSize(), it returns 320x460.

Yet, SDL_GetDisplayMode() returns 640x960 and 960x640 on this device.

Is this a matter of SDL for iPhone still having some kinks to work out, or something I don’t understand here?

-Vern

Yeah, I’m pretty sure this is wrong. What I think is happening is that
SDL is returning the UIWindow.frame dimensions. AIUI, these numbers
are ALWAYS in terms of what Apple calls “points”. On the 3GS there is a
one to one mapping between points and pixels, but on the higher res
versions, one point is two pixels.

It looks to me like the function SetupWindowData should be using a
UIScreenMode to source the values of SDL_Window::w and SDL_Window::h,
not the frame dimensions.On Wed, 18 Jan 2012 15:08:43 -0800 VernJensen wrote:

Testing on the iPhone simulator with retina display, if I create an
SDL window with 640x960 resolution, and then call SDL_GetWindowSize
(), it returns 320x460.

Retina display is a bit broken. I don’t have a retina display device to
help fix it. Ryan has it on is (long) TODO list, but if you want to take a
crack at it go right ahead!On Wed, Jan 18, 2012 at 6:08 PM, VernJensen wrote:

**
Testing on the iPhone simulator with retina display, if I create an SDL
window with 640x960 resolution, and then call SDL_GetWindowSize(), it
returns 320x460.

Yet, SDL_GetDisplayMode() returns 640x960 and 960x640 on this device.

Is this a matter of SDL for iPhone still having some kinks to work out, or
something I don’t understand here?

-Vern


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Do you know how it’s broken? As I said in my other mail I believe that
using the UIFrame dimensions for the window size is the wrong thing to
do. If you agree and this is the only problem it’s probably not that big
of a deal to fix it.On 19/01/2012 01:30, Sam Lantinga wrote:

Retina display is a bit broken. I don’t have a retina display device to
help fix it. Ryan has it on is (long) TODO list, but if you want to
take a crack at it go right ahead!

The attached patch fixes the problems that I have come across. It’s
basically as I described in my other mail in that on the retina devices
UIKit’s coordinate system is off by a factor of 2 compared to the actual
physical display.

It does raise another issue though. Now that I have 4 times the pixels
my app has become somewhat fill-rate bound. This isn’t really a problem,
I just need to render to a smaller area and adjust my projection to
scale up. I can see however that it might be annoying for people to take
existing performant code for 320480 and find that it doesn’t work so
well at 480
960.

I think there is a case for SDL advertising 320480 and 480320 display
modes on retina devices, then doing all the scaling internally to SDL;
essentially the same as I suggested in the previous paragraph but in
UIKit terms rather than OpenGL. I would appreciate people’s thoughts or
opinions on this.

In any case, with the attached patch things are certainly more correct
than the status quo so it should probably be committed. I can throw it
in bugzilla if needs be.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed…
Name: sdl2-ios-retina-fixes.diff
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20120123/ce42cfee/attachment.ascOn 19/01/2012 01:30, Sam Lantinga wrote:

Retina display is a bit broken. I don’t have a retina display device to
help fix it. Ryan has it on is (long) TODO list, but if you want to
take a crack at it go right ahead!

Yes please throw it in bugzilla. Thanks!

I agree that advertizing the lower res modes and letting UIKit scale it in
that case is the right way to go, but I don’t know what the interaction
with the rest of SDL would be.On Mon, Jan 23, 2012 at 10:14 AM, Tim Angus wrote:

On 19/01/2012 01:30, Sam Lantinga wrote:

Retina display is a bit broken. I don’t have a retina display device to
help fix it. Ryan has it on is (long) TODO list, but if you want to
take a crack at it go right ahead!

The attached patch fixes the problems that I have come across. It’s
basically as I described in my other mail in that on the retina devices
UIKit’s coordinate system is off by a factor of 2 compared to the actual
physical display.

It does raise another issue though. Now that I have 4 times the pixels my
app has become somewhat fill-rate bound. This isn’t really a problem, I
just need to render to a smaller area and adjust my projection to scale up.
I can see however that it might be annoying for people to take existing
performant code for 320480 and find that it doesn’t work so well at
480
960.

I think there is a case for SDL advertising 320480 and 480320 display
modes on retina devices, then doing all the scaling internally to SDL;
essentially the same as I suggested in the previous paragraph but in UIKit
terms rather than OpenGL. I would appreciate people’s thoughts or opinions
on this.

In any case, with the attached patch things are certainly more correct
than the status quo so it should probably be committed. I can throw it in
bugzilla if needs be.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Yes please throw it in bugzilla. Thanks!

http://bugzilla.libsdl.org/show_bug.cgi?id=1394

I agree that advertizing the lower res modes and letting UIKit scale it
in that case is the right way to go, but I don’t know what the
interaction with the rest of SDL would be.

Not much, I think. The way Retina support works, using the UIKit (half
physical screen) resolution is sort of the default anyway. I’ll have a
quick look now and see how complicated it’ll be. My hunch is not very,
though I’ll probably regret saying that :).On 23/01/2012 16:05, Sam Lantinga wrote:

I’ve updated the bug with a new version of the patch which advertises
the lower res modes. Copy and pasted from the bug:

"Alright, this new version implements reporting of the "non-scaled"
display on Retina devices, i.e. 320x480 as well as 640x960. If the
former is selected (using SDL_SetWindowDisplayMode +
SDL_SetWindowFullscreen) a scale of 1.0 is used instead of [UIScreen scale].

The only slight gotcha that I’ve come across is the fact that calling
SDL_SetWindowFullscreen unavoidably disables the iOS status bar. I’ve
tried to disconnect the two things but this implies that a window is
both fullscreen and its dimensions are not the same as the display
mode’s. For example, the display mode might be 320x480, but with the
status bar enabled the window size will be 320x460. In itself this is
fine, but this breaks the wide spread assumption that the two sets of
dimensions are identical and with it various other parts of SDL. So I’ve
left that alone for now. It’s not really a big deal though, since I
imagine most users will want the status bar disabled anyway."On 23/01/2012 16:37, Tim Angus wrote:

On 23/01/2012 16:05, Sam Lantinga wrote:

Yes please throw it in bugzilla. Thanks!

http://bugzilla.libsdl.org/show_bug.cgi?id=1394

I agree that advertizing the lower res modes and letting UIKit scale it
in that case is the right way to go, but I don’t know what the
interaction with the rest of SDL would be.

Not much, I think. The way Retina support works, using the UIKit (half
physical screen) resolution is sort of the default anyway. I’ll have a
quick look now and see how complicated it’ll be. My hunch is not very,
though I’ll probably regret saying that :).