Sorry your browser is not supported!

This issue has come up many times. In addition to using the SetOrientationAllowed command, it is necessary to set some platform specific project values.

For iOS, it has been discussed before and is relatively simple. First set the desired orientations in both the iPhone/iPod and iPad Deployment Info sections under the Summary tab when your TARGET app is selected. Then you make sure to have the correct lines in <yourapp>-Info.plist (UIInterfaceOrientation sets the initial app orientation and UISupportedInterfaceOrientations has the list of allowed orientations):


The values to use for specific orientations are:
UIInterfaceOrientationPortrait - normal portrait, home button on bottom, AppGameKit orientation 1
UIInterfaceOrientationPortraitUpsideDown - reverse portrait, home button on top, AppGameKit orientation 2
UIInterfaceOrientationLandscapeLeft - normal landscape, home button on left, AppGameKit orientation 4 (four, not three)
UIInterfaceOrientationLandscapeRight - reverse landscape, home button on right, AppGameKit orientation 3 (three, not four)

There is no issue of initial black flash with iOS because of the use of the Default.png images (and there is one for every possible resolution, device and orientation).

I recently (thanks to Naphier) found out how to force an Android app to a specific initial orientation. This is done in the AndroidManifest.xml file (and make sure to make the change in the <appdir>/AndroidManifest.xml and <appdir/bin/AndroidManifest.xml):


The key line is: android:screenOrientation="reverseLandscape"

The values entered work like this (from this page and mentioning only the ones that we are likely to use):
"landscape" - Landscape orientation (the display is wider than it is tall). This is AppGameKit orientation 3 (home button on right on well behaved devices)
"portrait"- Portrait orientation (the display is taller than it is wide). This is AppGameKit orientation 1 (home button on bottom OWBD)
"reverseLandscape" - Landscape orientation in the opposite direction from normal landscape. This is AppGameKit orientation 4 (home button on left OWBD)
"reversePortrait"- Portrait orientation in the opposite direction from normal portrait. This is AppGameKit orientation 2 (home button on top OWBD)
"sensorLandscape" - Landscape orientation, but can be either normal or reverse landscape based on the device sensor. AppGameKit orient 3 or 4. But always one or the other.
"sensorPortrait" - Portrait orientation, but can be either normal or reverse portrait based on the device sensor. AppGameKit orient 1 or 2.
"sensor" - The orientation is determined by the device orientation sensor. The orientation of the display depends on how the user is holding the device; it changes when the user rotates the device. Some devices, though, will not rotate to all four possible orientations, by default. To allow all four orientations, use "fullSensor".
"fullSensor" - The orientation is determined by the device orientation sensor for any of the 4 orientations. This is similar to "sensor" except this allows any of the 4 possible screen orientations, regardless of what the device will normally do (for example, some devices won't normally use reverse portrait or reverse landscape, but this enables those).

I use "reverseLandscape" and it works very nicely. But it still didn't solve the issue of the AGKSplash.png file (in the assets directory) insisting on displaying as if the device were in portrait mode. This is something that needs to be settable in the core AppGameKit libraries somehow for Android.

from my supplemental post in the Android subthread
http://forum.thegamecreators.com/?m=forum_view&t=204959&b=46



Recording another finding here:
The res/layout/main.xml also contains a setting for android:orientation = "vertical"
If you set this to horizontal it might be early on enough to fix the orientation of the AGKSplash.png.

I can't tell since I don't use that and the android:screenOrientation = "sensorPortait" fixes my issue.

Another thing I wanted to point out is that sensorPortait is an intentional misspelling. The Android SDK that AGK10811 uses does not accept the correct spelling of portrait and has been fixed in future incarnations of the sdk, but AppGameKit just doesn't use it yet.

I hope this saves someone else the time I spent looking it up.

Also there are settings in the CoreForApp.h that look like they might override initial app settings, so if anyone is adventurous, feel free to give it a try, though the fix to the manifest solves my issues.

EDIT:
Can we get a sticky for this? Please

CoreForApp.h is not part of the Tier 2 Android file set, it is only for the Tier 1 bits. So, I cannot try tweaking in there for my Tier 2 project.

I tried looking at all the editable files for Tier 2 Android, but there really is only Core.cpp and I couldn't get it to believe that it was in landscape to start up. There is something in the pre-built libraries that gets executed when the app starts.

And, even with an AGKSplash.png file in the correct place, you still get a couple of seconds of black splash when the app starts. More on the first time it runs after installation.

So, I tried changing the settings in res/layout/main.xml (copied from v10811). However, it still didn't solve the issue of AppGameKit displaying a landscape AGKSplash.png as if it were portrait.

We need something that can be set in the template.h include file that will trigger AppGameKit going straight to landscape mode, before it even tries to display the AGKSplash.png file.

I tried copying the device width/height constants from the v10811 VS2010 template, but it had no effect in v1076.

I am reluctant to go to v10811 because I experienced depth display issues. Things that displayed at the correct depths (which change during the game) in v1076 just do not display properly in v10811.

Bummer that didn't work.
It would indeed be nice to have better control of orientation as well as screen size (in Windows).

I've fortunately not experienced any depth issues in 10811, but most of my stuff is either set to 1, 5, 10, or 10000 and the stuff that is 5 or 10 really don't matter too much.