While I was working on the “Cardflow” interface mode for CardSwitcher I had to work out get custom page widths and custom effects as you scroll through the cards, this is actually quite simple but I haven’t seen many posts on customising a UIScrollView. Most of the tips are spread across lots of different stackoverflow questions.
Problems with custom scrollview’s
To start with (actually while I was working on the first version of CardSwitcher) I looked into iCarousel, which has quite a lot of cool effects and a tableView style data source and delegate protocols. However as the first version of CardSwitcher was actually just a standard WebOS, or Safari tab’s style, linear layout that highlighted a problem with iCarousel (which joehewitt also noticed with iScroll), caused by the fact it doesn’t customize a UIScrollView but instead uses UIGestureRecognizers to do the scrolling itself (like UIScrollView itself).
However because of this the scrolling just feel wrong, the physics are off by a little bit. The bounce as you scroll of the edge, flicking and then how many pages it scrolls past before stopping and the paging effect all just feels off slightly.
In safari if you tap and hold down over an image you get a list of options which includes things not in the UIWebView’s standard popup menu, like saving the image.
In the previous parts of this tutorial we covered making the menu and making the basic game in Sparrow-Framework. Now we are going to refine the game and actually use the OpenFeint, that we set up at the beginning.
Some of the refinements we’ll be making.
- Adding scoring;
- Adding a pause menu;
- Improving the AI slightly;
- Add some settings
First, before we begin, a few notes about iPad compatibility. Although I’ve just been mentioning the AppDelegate_iPhone files, rather then both _iPhone and _iPad files, we have been using the window’s size rather then hard coding values. So you should just be able to copy and paste the code from below applicationDidFinishLaunching, with only 2 modifications.
- The OpenFeint initialisation code on the iPad needs to be done after [window makeKeyAndVisible];
- The game needs to initialised with “window.frame.size.width” and “window.frame.size.height” rather then ‘320’ and ‘480’;
First we are going to create a few new classes.
For the third part of my Complete iOS Game Tutorial series we will, finally, be using Sparrow-Framework and creating the game itself, which includes some basic collision detection and AI.
Now last time we made the base for the app, the main menu and the cool animations into the game. But we didn’t actually make anything in that game view did we.
At the moment you’ve got a cool main menu that then shows you a red square and leaves you stuck in the game view without being able to get back to the main menu.
So the next thing to do is make the game part of the app.
Now this is a universal app and I’ve chosen to only use the single Game class rather then a separate one for iPhone and iPad which means we will be doing everything, as much as possible, relative to the stages size rather then giving it absolute values.
UPDATE: After I posted my poorly added (never got round to taking into account scale or rotation for instance) implementation Shilo updated his origin point implementation (which uses the x and y directly) to avoid messing up the objects bounds and also to take into account the objects rotation and scale. Forum Post and Tutorial + Download Link.
When working with most things the x and y is positioned in the top right hand corner of the screen. However some things, like box2d, working with the x and y in different places on the screen (box2d uses the objects center point as it’s x and y point).
So until daniel implements it fully into sparrows core (probably in 1.2) I’ve written a little addition to SPDisplayObject which adds originX and originY which you can use instead of x and y.
Just modify these files……