Rotation breaks SDL2 rendering on Android

Hi,

I’ve come across a problem with rotation on Android. I’m using the latest
version from hg and Android 4.1.2 on a Samsung Vibrant.

If I use the SDL2 rendering API, rotation causes the rendering to mess up.
Starting from landscape, rotating to portrait is fine. But then after
rotating back to landscape, the rendering is offset in both x and -y
directions and is clipped. I tried out testspriteminimal and confirmed
that it happens with that too. See links below for screenshots of this
process (landscape, portrait, landscape). Going the other way has similar
problems. Portrait to landscape is fine, but going back to portrait
offsets the rendering in the y direction. I’ll link a screenshot of that
too.

Using OpenGLES directly, I don’t have this problem. I suspect that the
rendering API is not setting the viewport properly. Any thoughts, ideas,
fixes?

http://dinomage.com/open/SDL/landscape_ok.png
http://dinomage.com/open/SDL/portrait_ok.png
http://dinomage.com/open/SDL/landscape_broken.png
http://dinomage.com/open/SDL/portrait_broken.png

Jonny D

Okay, I found it.

The viewport width and height are not being updated when the device is
rotated. This makes the centering code in SDL_render.c (around line 119)
try to center x and y using incompatible dimensions (e.g. (portrait_w -
landscape_w)/2).

As an example…
Start with portrait. Viewport: (0,0,480,800)
Rotate to landscape. Viewport: (0,0,800,480)
Rotate back to portrait. Viewport: (-160,160,480,800)

The centering code uses:
viewport.y = (h - viewport.h)/2;
which is:
160 = (800-480)/2;
…because viewport.h was not updated to portrait before the render event
callback.

I’m not sure of the proper fix… I can make it work by setting the
viewport to the incoming w and h, but I don’t know about cases where the
viewport dims are intentionally different than the window dims. Also,
there’s the if(renderer->target) case that I’m not sure of. I’m attaching
a patch for this, but it needs a more experienced look-over.

Jonny DOn Fri, May 10, 2013 at 2:03 PM, Jonathan Dearborn <@Jonathan_Dearborn>wrote:

Hi,

I’ve come across a problem with rotation on Android. I’m using the latest
version from hg and Android 4.1.2 on a Samsung Vibrant.

If I use the SDL2 rendering API, rotation causes the rendering to mess up.
Starting from landscape, rotating to portrait is fine. But then after
rotating back to landscape, the rendering is offset in both x and -y
directions and is clipped. I tried out testspriteminimal and confirmed
that it happens with that too. See links below for screenshots of this
process (landscape, portrait, landscape). Going the other way has similar
problems. Portrait to landscape is fine, but going back to portrait
offsets the rendering in the y direction. I’ll link a screenshot of that
too.

Using OpenGLES directly, I don’t have this problem. I suspect that the
rendering API is not setting the viewport properly. Any thoughts, ideas,
fixes?

http://dinomage.com/open/SDL/landscape_ok.png
http://dinomage.com/open/SDL/portrait_ok.png
http://dinomage.com/open/SDL/landscape_broken.png
http://dinomage.com/open/SDL/portrait_broken.png

Jonny D

-------------- next part --------------
A non-text attachment was scrubbed…
Name: android_rotate_viewport_dims.diff
Type: application/octet-stream
Size: 963 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20130513/f7f98f60/attachment.obj

Bug reported here:
http://bugzilla.libsdl.org/show_bug.cgi?id=1849

Jonny DOn Mon, May 13, 2013 at 11:18 AM, Jonathan Dearborn <@Jonathan_Dearborn>wrote:

Okay, I found it.

The viewport width and height are not being updated when the device is
rotated. This makes the centering code in SDL_render.c (around line 119)
try to center x and y using incompatible dimensions (e.g. (portrait_w -
landscape_w)/2).

As an example…
Start with portrait. Viewport: (0,0,480,800)
Rotate to landscape. Viewport: (0,0,800,480)
Rotate back to portrait. Viewport: (-160,160,480,800)

The centering code uses:
viewport.y = (h - viewport.h)/2;
which is:
160 = (800-480)/2;
…because viewport.h was not updated to portrait before the render event
callback.

I’m not sure of the proper fix… I can make it work by setting the
viewport to the incoming w and h, but I don’t know about cases where the
viewport dims are intentionally different than the window dims. Also,
there’s the if(renderer->target) case that I’m not sure of. I’m attaching
a patch for this, but it needs a more experienced look-over.

Jonny D

On Fri, May 10, 2013 at 2:03 PM, Jonathan Dearborn <@Jonathan_Dearborn>wrote:

Hi,

I’ve come across a problem with rotation on Android. I’m using the
latest version from hg and Android 4.1.2 on a Samsung Vibrant.

If I use the SDL2 rendering API, rotation causes the rendering to mess
up. Starting from landscape, rotating to portrait is fine. But then after
rotating back to landscape, the rendering is offset in both x and -y
directions and is clipped. I tried out testspriteminimal and confirmed
that it happens with that too. See links below for screenshots of this
process (landscape, portrait, landscape). Going the other way has similar
problems. Portrait to landscape is fine, but going back to portrait
offsets the rendering in the y direction. I’ll link a screenshot of that
too.

Using OpenGLES directly, I don’t have this problem. I suspect that the
rendering API is not setting the viewport properly. Any thoughts, ideas,
fixes?

http://dinomage.com/open/SDL/landscape_ok.png
http://dinomage.com/open/SDL/portrait_ok.png
http://dinomage.com/open/SDL/landscape_broken.png
http://dinomage.com/open/SDL/portrait_broken.png

Jonny D

I’m not sure of the proper fix… I can make it work by setting the
viewport to the incoming w and h, but I don’t know about cases where the
viewport dims are intentionally different than the window dim

Also, be aware that some Android devices and OS versions (and forks
like Amazon Kindle) don’t necessarily use the same window dimensions
when rotated. The status and menu bars may end up getting a different
height in the different orientation which may alter the window size.
It is annoying as heck.

-Eric–
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/