02-27-2012 01:58 PM
I just tried the HellowWorldDisplay from 2.0.0-beta3 with the orientation to landscape in the bar-descriptor. When I run it the image is squished. It might be your size swapping logic, I didn't really look that hard.
When running some tests on this sample I noticed this bit of code that looks promising.
screen_display_mode_t screen_mode; rc = screen_get_display_property_pv(screen_disp, SCREEN_PROPERTY_MODE, (void**)&screen_mode);
I tried all the different cases I could think of and the screen width and height always reported 1024x600. So I'm guessing it's returning the raw display dimensions without any OS transformations applied. I couldn't see any real docs for SCREEN_PROPERTY_MODE, even a link to the screen_display_mode_t would make it more apparent. I ended up using SCREEN_PROPERTY_SIZE and that is why the values were likely changing.
Is the SCREEN_PROPERTY_MODE is indeed returning the screen dimensions relative to the device being held so that the BlackBerry logo is at the top?
02-27-2012 06:29 PM
I just tried the HelloWorld and it locks orientation to landscape as expected. What are your ndk and os builds?
Also, are you sure that you dont have orientation set to portrait? This is the only setting that will produce a squished image in unmodified sample.
Now, in terms of libscreen calls. SCREEN_PROPERTY_MODE does provide a display size irrepective of the current orientation. So, in case of a PlayBook it is always 1024x600. Note that you'll need additional logic to make this work in general case - i.e. devices on which angle 0 would correspond to a portrait orientation.
And yes, SCREEN_PROPERTY_SIZE will change depending on the current orientation angle. These two facts, and a value of ORIENTATION env variable should give you all the information you need to determine the size of you libscreen buffers.
Note that in case you have selected Auto-orient - ORIENTATION will reflect your current angle. In case you have picked either Landscape or Portrait - it will reflect the angle that you should be in.
I am working with our technical writers team to post a detailed tutorial on this soon.
02-27-2012 07:06 PM
Yes it's squished in portrait. I must have misread something in one of the previous posts because I thought this sample was designed to handle both.
Thank you for verifying how SCREEN_PROPERTY_MODE works.
The whole orientation thing can be a problem because as you mentioned there could be devices in the future that has portrait defined with an angle of zero. IIRC the docs say that an angle of zero indicates the orientation where you can read the BlackBerry logo. This implies the default/intended orientation when holding the device.
Now let's say RIM comes out with a device like the Bold that has a screen that is 480x360 (or something). What would one consider that to be in, Portrait or Landscape? This is an issue because you might have an old top down retro shooter that wants the game to be in portrait mode. The thing is that you don't want someone with this Bold like device holding it on it's side. Get my meaning?
02-27-2012 07:24 PM
What I meant, is that bbutil_init_egl and bbutil_rotate_screen_surface are designed to function with any permutation of screen sizes and deployment settings.
The sample itself renders a 10x6 full-screen texture as a background. In case of a 6x10 screen size - we get the squishing effect.
Now, you have raised several important points.
-> This implies the default/intended orientation when holding the device
This is actually application dependent. We have seen applications that need to be started in portrait. One can envision an app that wants to have sound control buttons at the bottom (i.e. angle 180). It all comes down to UX in the end.
-> Now let's say RIM comes out with a device like the Bold that has a screen that is 480x360
In this case we are looking at a landscape device as width is bigger than height,
->The thing is that you don't want someone with this Bold like device holding it on it's side.
Well, this is a typical problem with porting an app to a device that it was not intended for. So, two ends of the spectrum of possible solutions are
- rewritethe UI of the app to fit the new device perfectly
- leave UI as is and end up with an app that is difficult to use on this particular device and/or looks crappy
There are several aspects that determine which end of the spectrum one should lean towards, but there is no single rule for something like this.