Enhancement- Orientation Detection about cocos2d-iphone HOT 18 CLOSED

I think this is not cocos2d specific.

anyway, can you provide me with some code to detect this so I can think of 
including
it in cocos (or not).

tnx.

actually the game i'm developing uses both portrait and landscape views, and i 
though
it would be a nice feature to detect when the user switches each view.

I haven't implemented it yet, but if i do i'll make sure to shoot you an email.

Thanks
Ashar

Wont fix.
Use [[UIDevice] orientation]

One approach:
In CCDirector...
Add BOOL wantOrientationUpdates, default NO.
Have setter and resume call: [[UIDevice currentDevice] 
beginGeneratingDeviceOrientationNotifications];
and schedule repeating 1/4 second timer to test notification status: [[UIDevice 
currentDevice] orientation]
ignoring cases: UIDeviceOrientationUnknown, UIDeviceOrientationFaceUp, 
UIDeviceOrientationFaceDown
Have pause call: [[UIDevice currentDevice] 
endGeneratingDeviceOrientationNotifications];
and unschedule the timer.

While the above detection code is not difficult; this feature request has 
issues with applyLandscape/visit/draw 
since currently the desired orientation is coupled to CCDirector instead of 
CCScene, affecting:
(A) Transitions.
(B) Scene graph (visit tree) when it includes both Fixed-Oriented Nodes and 
Non-Fixed-Oriented Nodes.

In other words, CCDirector should only store the actual ccDeviceOrientation, 
but each CCScene should store 
the desired fixed-elements orientation.

For (A), transitions fail because CCDirector calculates the anchorPoint and 
rotation (applyLandscape) rather 
than the scene doing the calculation based on a scene attribute.
For (B), sometimes an artist may want a background (or whatever) to have a 
fixed orientation for aesthetic 
reasons (aspect ratio, etc), but have text (or whatever) rotate and resize 
depending on the actual device 
orientation.

Note: Making this change will break functionality/compatibility, since 
currently users use the 
deviceOrientation to mean "desired/use this", not the actual orientation as 
reported by the accelerometer.

Note: Above note has no relation to the mapping between ccDeviceOrientation and 
UIDeviceOrientation by 
equivalence class. =) I agree ccDeviceOrientation enum includes the interesting 
cases reported from the 
accelerometer.

One appealing benefit of this feature/change would be the ability to create 
new/interesting transitions or 
simply trigger different ones when desired orientation differs between incoming 
and outgoing scenes.

I'm a bit lost regarding this feature.
What are the benefits of it ?
why the director should notify the orientation ?

This change is complicated, and if done, is probably better scheduled as a 2.0 
feature.

Benefits:
(I) Scene Transitions: could be written or changed to accept incoming and 
outgoing scenes with different 
desired orientations, and smoothly transition between them.  (Currently the 
switch is immediate.  Do you have 
a work around?)
(II) Scenes could be modified such that text could be auto-rotated, scaled, and 
possibly animated after a user 
reorients the device (for their own reason), without changing the orientation 
of some static scene elements 
such as background (which honors the desired orientation set in CCScene).  Such 
autorotation could be called 
a SceneElementOrientationAnimation (or whatever).

In other words, the artist can choose to force scene orientation for some 
elements, while letting others 
respond to user orientation input (and change accordingly), without changing 
the whole scene.

So the two big changes are:
(C) Make CCScene independent of CCDirector for orientation transforms.
(D) Allow non-static scene elements (such as text) respond to user orientation 
changes, but let the 
programmer/artist force static elements to keep their orientation.

thanks. Now I understand the feature. I think it is better to schedule it for 
2.x.

resolution: from "won't fix" to "accepted"

Can we open a discussion about this on the forums? I don't understand what this 
has
to do with cocos2d. It seems like it should be up to the application logic to 
handle
this.

Ignore (D) for now, and just consider (C).

The first change ((C) above) is the cocos2d change that matters most.  
Currently, CCDirector performs 
"applyLandscape" which forces the orientation for all scenes.  By moving this 
into CCScene, the scene 
becomes in charge of the desired orientation.

Also currently, the meaning of orientation in CCDirector is "apply this 
transform"... It does _not_ mean, "this is 
the current device state".

What to do about (D) is another discussion.

[deleted comment]

The whole issue of device orientation (how the actual device is currently 
positioned)
versus interface orientation (how your view is oriented) versus how your opengl
matrix is oriented (director's rotation) is going to be really important now 
that
iPad is out and Apple wants developers to support as many orientations as 
possible.

Here's what I wrote on the forum about the current state of the view hiearchy 
and
cocos2d:

There is a fundamental problem with the way cocos2d is handling rotation.

Apple expects you to use a viewcontroller to contain your view hiearchy. Adding 
this
in is a simple fix, but making cocos2d work correctly with it is not.

Having a view controller allows you to respond to which orientations you will 
support
and when rotated it will do the following:
1. Set your view controller's interfaceOrientation property
2. Rotate your view controller's view by modifying the transform property 
inside of a
UIView animation.

Cocos2d operates under the assumption that you do not want to rotate your view
(because on older devices this causes a performance penalty, though on newer 
hardware
like 3gs and ipad there is no such penalty) so it offers you a way to rotate 
your
openGL transform matrix instead by telling the director what orientation to use.

The problem with this approach is that if you actually want to start 
cooperating with
other things that read the interfaceOrientation property from your 
viewcontroller
(which is readonly btw, and is only updated by private Apple apis during 
rotation)
then cocos2d (and every other iphone gles game framework I could find) doesn't 
handle
it properly.

Here's a high level of what needs to happen to get everything in order:
1. Use a custom UIViewController which uses EAGLView for its view
2. Intercept attempts to rotate the view and reset the transform to the 
identity matrix.
3. Apply your rotation in openGL based on the viewcontroller's 
interfaceOrientation
property
4. Converting coordinates should always use the viewcontroller's 
interfaceOrientation
property and not the device's orientation.

I have this all working (I think, though not 100% tested) in my current 
project, but
I won't have time to make a patch for cocos2d for a while because I'm in the 
final
stages of game development and I'm not using CCDirector anymore as I have 
written my
own game loop/UIView+openGL coordinating code.

If someone else would like to work on this, feel free to ping me for input. 

I'll ping you in a few weeks regarding this issue.

Hi MyBuudyCJ,

Any chance of some pointers on this.

1. - I think I have this covered :)
2. - not sure where this would go - in the ViewController?
3. - even less sure of this, OpenGL noob
4. - sounds more manageable...

Thanks,
Chris

I did some work to actually disable the rotation code in cocos2d. This adds a 
new option to disable the code and let UIViewController handle it instead. You 
can find my blog post about it here: 
http://ohminteractive.se/2010/07/15/cocos2d-and-orientation-madness/ and the 
code is up on github 
http://github.com/ohminteractive/cocos2d-iphone/commit/997bb1a4c9b9edc312e8eae17
4cd4a4720e57485.

Maybe I should file a separate bug for the inclusion of that option?

@tobiashieta:
I think that this issue is fixed in v0.99.4
v0.99.4 includes a new test called "bug-914", among other things it also test 
issue #924.

If you try that tests you'll see that it is possible to rotate in all 
directions the EAGLView (ipad or iphone) and still everything works as expected.

Please, if the above mentioned solution (test case for issue #914) doesn't 
work, could you open a new bug ? Thanks!


Resolution: Won't fix. See "bug-914" test case to see how to use it.