Tag Archives: code

Custom rotation/orientation, and almost too much code

I have my major iPhone project game-app organized in this manner:

Custom class for appplication delegate class (as all apps have)

it has a generic UIWindow as the view property.

To this window, I add a background wood image.

Then the app delegate creates an instance from a nib, of my main game object view-controller-subclass.  I actually use this view controller subclass as the main model of the game, instead of separating it out to form a more appropriate model-view-controller relationship model.

The game object has a custom UIView subclass, NOT the one for the OpenGL view.

This view is permanently in UIInterfaceOrientationLandscapeRight (the default orientation set in the Info.plist).
Extra trivia: when an orientation change occurs, I manually rotate subviews of the main game view individually.  This is done by  picking one of my five global CGAffineTransform variables created with assigned values

CGAffineTransform transRot0 = CGAffineTransformMakeRotation( 0 );
CGAffineTransform transRotMinus90 = CGAffineTransformMakeRotation( – M_PI / 2 );
CGAffineTransform transRot90 = CGAffineTransformMakeRotation( M_PI / 2 );
CGAffineTransform transRotMinus180 = CGAffineTransformMakeRotation( – M_PI );
CGAffineTransform transRot180 = CGAffineTransformMakeRotation( M_PI );

The two 180s are very important, only if using animations to transition with style.  And that’s what I am doing (in some cases).
The UIInterfaceOrientationLandscapeRight is the same thing as UIDeviceOrientationLandscapeLeft (when you rotate the iPhone or iPod touch from having the home-button down = portrait, to having it on the right-side = device landscape left, the interface must rotate the opposite direction = landscape right, to maintain the same upward direction so you don’t have to tilt your head).  The direction of positive rotation is clockwise,  so if someone starts the app and has the home button down = device/interface portrait, the interface must rotate counter-clockwise 90 degrees, thus I assign transRotMinus90.
NOW IF the device is rotated again to device-landscape-right/interface-landscape-left, all my subviews including the play-screen and main menu will need to be rotated to a 180 degree transform rotation. But because the view was previously a Minus-90 degree, the next rotation should be a Minus-180 degree.  If using animations and assigning all subviews a 180 degree rotation from minus-90 degrees, rotating from portrait to device-landscape-right will have a terrible looking 270 degree opposite rotation.  Again, it isn’t important to do minus-180 if there is no animation.

That’s a long-winded orientation discussion.

And as mentioned, the game-viewcontroller has a custom subclass UIView.  It has two primary views added as subviews (there are other subviews which are not important for discussion).  The first primary view is a view from a custom subclass of UIViewController controlling the main menu, and the second of the two primary views is a custom subclass of UIView which is for the OpenGL graphics.

And I haven’t been working on this today, but I mentioned all of my game’s orientation methods are contained within the main game class, not the custom subview class.

All of this orientation code, and much more (multiple levels of initializing and setup, haha) combine to a pretty large line count – today I went over 6000 lines in this one file.

Everything is very well organized still, so I have no problem navigating or finding things.  Woohoo.  Otherwise, it would be a colossal nightmare.

Leave a comment