I’m having trouble getting smooth (3d) performance on mobile devices with not so much power but massive screens resolutions (e.g. some android devices). One solution would be to make the framebuffer smaller than the native resolution and let the platform upscale it to the screen. This would cut down the amount of fragment shader operations dramatically that seem to be the bottle neck for me.
I could of course render to a texture in my program and leave SDL alone, but it would waste memory and add one more render step. I think it would be nicer if SDL offered a solution out of the box to get the same result by just making the framebuffer smaller than the native resolution. I made a small ungly hack to the SDL Android activity and got it working (on android at least).
I think it would be nice if I could just check the actual native resolution with SDL_GetDisplayMode, and if necessary give some smaller resolution in SDL_CreateWindow(). Then the window would seem to be that size for my drawing code, but SDL would do the scaling transparently behind the scenes. Currently the width and height parameters of SDL_CreateWindow seem to be totally ignored on both ios and android. Maybe the SDL_WINDOW_FULLSCREEN_DESKTOP could be used to select the native resolution regardless of the given values, but SDL_WINDOW_FULLSCREEN would use a framebuffer of the requested size.
Do you see problems with this? I’m not entirely sure if this is actually saving memory or if the platform just then automatically creates some intermediate buffer instead of me creating one.
Doesn’t SDL_WINDOW_FULLSCREEN_DESKTOP effectively render to a
framebuffer of the requested size then upscale it? You’d pretty much
have all the work already done. Just beware of different aspect
ratios.
2014-06-28 21:11 GMT-03:00, ollika <olli.kallioinen at iki.fi>:> I’m having trouble getting smooth (3d) performance on mobile devices with
not so much power but massive screens resolutions (e.g. some android
devices). One solution would be to make the framebuffer smaller than the
native resolution and let the platform upscale it to the screen. This would
cut down the amount of fragment shader operations dramatically that seem to
be the bottle neck for me.
I could of course render to a texture in my program and leave SDL alone, but
it would waste memory and add one more render step. I think it would be
nicer if SDL offered a solution out of the box to get the same result by
just making the framebuffer smaller than the native resolution. I made a
small ungly hack to the SDL Android activity and got it working (on android
at least).
I think it would be nice if I could just check the actual native resolution
with SDL_GetDisplayMode, and if necessary give some smaller resolution in
SDL_CreateWindow(). Then the window would seem to be that size for my
drawing code, but SDL would do the scaling transparently behind the scenes.
Currently the width and height parameters of SDL_CreateWindow seem to be
totally ignored on both ios and android. Maybe the
SDL_WINDOW_FULLSCREEN_DESKTOP could be used to select the native resolution
regardless of the given values, but SDL_WINDOW_FULLSCREEN would use a
framebuffer of the requested size.
Do you see problems with this? I’m not entirely sure if this is actually
saving memory or if the platform just then automatically creates some
intermediate buffer instead of me creating one.
Does it really? Also for purely OpenGL use? I’m not using the SDL 2D api
For me it seems that SDL_WINDOW_FULLSCREEN_DESKTOP just starts the app in the same display mode that the desktop currently uses. And on mobile it doesn’t seem to do anything special.
Sik wrote:> Doesn’t SDL_WINDOW_FULLSCREEN_DESKTOP effectively render to a
framebuffer of the requested size then upscale it? You’d pretty much
have all the work already done. Just beware of different aspect
ratios.
No, it always uses the desktop’s resolution with no post-process scaling unless you do it yourself or you use SDL_Render and its SetLogicalSize function.
SDL’s iOS code for Retina displays adds a non-retina fullscreen mode you can choose, but actually using that might be bugged right now.> On Jun 28, 2014, at 9:53 PM, Sik the hedgehog <sik.the.hedgehog at gmail.com> wrote:
Doesn’t SDL_WINDOW_FULLSCREEN_DESKTOP effectively render to a
framebuffer of the requested size then upscale it? You’d pretty much
have all the work already done. Just beware of different aspect
ratios.
I did a bit more testing and made a small hack for both ios and android where just by (not) changing the size of the framebuffer the resulting renders are upscaled pretty much automatically to the device screen by the platform.
I was thinking about the window creation params on ios and android and how they would be more in line with the behavior on the desktop environments:
SDL_WINDOW_FULLSCREEN_DESKTOP => Use the device native screen resolution. The user specified width and height ignored.
SDL_WINDOW_FULLSCREEN => Use the user specified width and height (but scale the result to the native resolution)
This way from the user point of view both SDL_WINDOW_FULLSCREEN_DESKTOP and SDL_WINDOW_FULLSCREEN would work pretty much identically to the desktop environments (as on LCD displays fullscreen in any other mode than the display native res will be using scaling too). If neither flag is defined, one possibility would be to just use the requested window size and position and not do any scaling. Don’t really know if this would be even useful, but it should be possible too. Another option would be to just use full native res with the status bar if neither fullscreen mode is defined.
In addition, SDL_WINDOW_RESIZEABLE could be used to indicate that changing the device rotation is allowed to give a “window resized” callback. But I haven’t really thought or even tested how the rotation stuff works currently.
If SDL devs think this makes sense I could try to clean up my hacks and send a patch.
That?s not quite how SDL_WINDOW_FULLSCREEN works on desktops. It changes the physical display mode of the monitor. Since monitors only support a handful of display modes (or maybe it?s up to the video driver, but regardless?), I believe SDL will choose the next-largest supported display mode if you request an unsupported size in SDL_CreateWindow.
For example, my laptop display doesn?t support a 1280x720 display mode, so if I try to create a SDL_WINDOW_FULLSCREEN window with that size, it?ll automatically use 1280x800 instead.
Whether display modes with non-native aspect ratios stretch or have black bars is also up to the video driver I think.On Jun 30, 2014, at 1:42 AM, ollika <olli.kallioinen at iki.fi> wrote:
I was thinking about the window creation params on ios and android and how they would be more in line with the behavior on the desktop environments:
SDL_WINDOW_FULLSCREEN_DESKTOP => Use the device native screen resolution. The user specified width and height ignored.
SDL_WINDOW_FULLSCREEN => Use the user specified width and height (but scale the result to the native resolution)
This way from the user point of view both SDL_WINDOW_FULLSCREEN_DESKTOP and SDL_WINDOW_FULLSCREEN would work pretty much identically to the desktop environments (as on LCD displays fullscreen in any other mode than the display native res will be using scaling too). If neither flag is defined, one possibility would be to just use the requested window size and position and not do any scaling. Don’t really know if this would be even useful, but it should be possible too. Another option would be to just use full native res with the status bar if neither fullscreen mode is defined.
Whether display modes with non-native aspect ratios stretch or have black
bars is also up to the video driver I think.
It’s up to the monitor actually, though some video drivers may provide
fake resolutions (I know Nvidia drivers used to do 320?200 and 640?400
by letterboxing a 640?480 screen, though they eventually removed
support for those resolutions).
OS X always letterboxes. I don?t use Windows too frequently (and I look at my video driver settings even less frequently), but I think AMD?s CCC has an option for whether to letterbox.
Regardless of whether that?s implemented in the video driver of the physical display, it?s still not up to SDL or the SDL user.On Jun 30, 2014, at 2:37 AM, Sik the hedgehog <sik.the.hedgehog at gmail.com> wrote:
2014-06-30 2:06 GMT-03:00, Alex Szpakowski <@Alex_Szpakowski>:
Whether display modes with non-native aspect ratios stretch or have black
bars is also up to the video driver I think.
It’s up to the monitor actually, though some video drivers may provide
fake resolutions (I know Nvidia drivers used to do 320?200 and 640?400
by letterboxing a 640?480 screen, though they eventually removed
support for those resolutions).
Good point about fullscreen always finding the closest supported resolution. In that sense the current implementation is consistent from platform to platform. On mobile where there is only one supported resolution so it will always be selected regardless of the given width and height.
Regarding the scaling, I feel that at least on PC hardware the default behavior is usually to scale. If I would be playing a game that I can’t run properly on my fullscreen resolution and letterbox would be the only option, I would be very unhappy. I had a laptop where I had to change some bios setting to enable scaling if I remember correctly.
I still think that it would be handy to provide this kind of scaling support for ios and android where the user is now confined to using the full native resolution (for the use case I mentioned in my original post). I feel that rendering to a texture would add an unnecessary step to my app when all I really need is to be able to set the framebuffer size independently from the device screen resolution.