I had an idea for an app that would require me to implement these little sprites that would require basic physics features like gravity, acceleration, etc... so naturally I looked into a game loop for the iPhone, there were plenty of threads on this, but what I am trying to understand is that I want to be able to create these sprites and have them behave naturally using a game loop, but still have full "standard" iPhone interaction, i.e. touches, pinching, swiping, core animation, core data, etc...
Is this just as simple as implementing a game loop on a background thread and updating sprites on that thread then doing the standard operations on the main UI thread (except of course for obvious background tasks)?
I would like some general overview of this type of thing if thats possible.
I wanted the same thing, but the iPhone SDK is all about async and callbacks and it's better to roll with the framework rather than fight it. If Cocos2d does not satisfy you, you could look into hooking into NSRunLoop.
With regards to CADisplayLink: I noticed a drop in performance (decreased triangle throughput) when using CADisplayLink with OpenGL ES (which you have stated you are not using so I will not elaborate further).
In Xcode try creating a iPhone OpenGL ES project. Just build and run with the default code. You should see a box moving up and down. This simple example should give you an insight into animating objects and how the OS version of the device matters. The OpenGL view is based off a normal view that you can attach gesture watchers to.
Check out one of the available game physics engines. Cocos2D is a good place to start: http://www.cocos2d-iphone.org/ -- free and lots of resouRces to get started with.
Related
I am going to make a 2D iPad game today, but I do not want to use a game framework. I am more interested in how the framework is created, how to program the physics, and other low level topics.
So, if I'm not using a framework, how do I start? Is the first step to create an OpenGL based app in XCode?
OpenGL would be a place to start, but i would look through the cocos2d source, and see how various things are being done in that.
To program a 2D game from the ground up, especially if you're new to iOS, I don't see any reason to use anything other than the CoreGraphics and CoreAnimation APIs. Any bitmap-based imaging is typically done via OpenGL behind the scenes.
I have been building a game in cocos for a while now I it has just occurred to me that it might just be a whole lot easier to use UIKit.
Could you please help me weight up the pros and cons, and share some experiences you have.
Here is my basic list of advantages for each. I feel I dont know enought about cocos to make a informed decision which is best.
Cocos
Game engine comes for free. Pause / resume callbacks every frame
Sprite animations
Uses open GL (is this true? is this an advantage?)
...Help me think of some more!
UI Kit
Far more Help / Documentation / Sample Code
Familiar for iPhone programmers
Easy to handel touch
Easy view animations
Easy to customise
Faster loading times? (is this true?)
Any feedback would be great!
EDIT: I have just seen a developer video (on an open GL game called Quest) where they used UI Kit for the UI elements, drawn over the top of the GL View. Is this possible / practical with cocos?
Cocos2d uses OpenGL for drawing its sprites, movements, and particles. Trying to use Quartz/Core Graphics (which is NOT accelerated!) is fundamentally much slower and power hungry.
Cocos2d is a sprite library with a scenegraph first and foremost. You would be duplicating effort to make a scenegraph using UIKit.
There are lots of nice freebies that work within Cocos which you would have to develop from the ground up.
So, in short: It draws way faster than CPU bound drawing calls, it provides 95% of what most sprite based games need without reinventing the same thing over and over, and is free.
Although UIKit is incredibly useful for gaming, Cocos2D offers a variety of easier ways to accomplish many common game-making operations. For instance, it has the ability to create easy scrolling-tile games (very common and very popular) using a simple few lines of code to import a "Tiled" map set. In terms of some of the benefits of UIKit over Cocos2D that you mentioned, they are very easy to accomplish in Cocos2D, as well.
Touch handling:
This is as easy as replacing the "touchesBegan" method of UIKit with "ccTouchesBegan" and setting self.isTouchEnabled = YES in the init method.
Animations:
This is so much easier in Cocos2d, mainly because frame rate and animation issues are solved. In UIKit, you cannot use CoreAnimation to move an object while still implementing collision detection. You would have to animate the object with an NSTimer. In Cocos2d, you can easily animate objects (called sprites) and still use collision detection and interaction with the object.
More Help/Documentation:
Cocos2D offers an incredible amount of documentation and, even more so, examples of code! If you can't find it there, there is a growing number of iPhone game developers who implement Cocos2D in their apps and are willing to help many problems.
If you are planning on developing games for iPhone, and not just general apps for productivity, music, etc., I highly suggest Cocos2D. Remember, you can always still find ways to combine this and UIKit for many operations! Those operations aren't completely lost!
OK, I'm still brand new to iPhone development. I have a free game on the app store, Winner Pong, but it's just a Pong clone (who would've guessed) that uses the standard UIImageViews for the sprites. Now I want to do something a little more complicated, and port my game for the Xbox 360, Trippin Alien, to the iPhone. I obviously can't keep using UIImageViews, so I was wondering which would be better to learn: the simpler, but performance-hindering Qurtz2D, or the smooth-running but dauntingly complex OpenGL ES.
My game is basically a copter game, with about 8-10 sprites on screen plus a simple particle system (video here). Not too complicated, but performance does matter. My only prior game programming experience is in Microsoft's XNA and C#, which has a built in SpriteBatch framework that makes it incredibly easy to draw, scale, and rotate pre-rendered sprites on screen. Is it worth it to learn OpenGL ES? How big is the performance gap? Is quartz really that simple?
Also, if anyone knows of any tutorials for either one, please, post them here. I need as much help as I can get.
Look through code samples of each to actually see the complexity. You might find that OpenGL isn't so daunting.
Regarding the performance. Core Animation, which Quartz2d is part of, uses OpenGL behind the covers, so for simple sprite animations, I would expect your game to perform fairly well.
I would also glance over the programming guide for each before making your final decision.
Another alternative is to use something like Unity. I recently just started playing around with the trial version of this development environment and if you're mostly doing game development with graphical objects and sprites, this may be one option to consider. You can script in C#, Javascript, or Boo. The development environment allows you to graphically setup your scenes and levels. You can then attach scripts to graphical objects for animation to handle user events, etc.
One downside for Unity, which I've heard from others is that if you want to use the familiar UI controls from UIKit, it's not so easy to instantiate them...I haven't verified this myself.
When you drag an iphone GUI element like a list, it scrolls in a physics correct way, and also has a nice bounce effect at the end.
I would like to write a GUI element in my game, without using UIKit. I wonder where is the code implementing this, and if I can use it instead of trying to write something similar.
Any ideas?
I think that a physics engine would be overkill for just animating a gui element (unless you already have a physics engine in your game).
You could try using animations but I've no experience of doing this without UIKit but I suppose you would start here?
If you didn't want to use Core Animation, I would take a look at Robert Penner's easing equations - they're in actionscript but are pretty simple to port to C and would be a good start to get your own animation code started.
Hope this helps,
Sam
You can perhaps use animations to achieve this, you can define animation paths for bouncing or doing whatever it is you need and activate them when needed. I think the example project MoveMe can help you out
I can recommend the O'Reilly book "Physics for Game Developers" by David Bourg, which has great coverage of algorithms and code for all sorts of simulations. You probably want to start with motion affected by drag for the flick and gradual slowing, then look at a spring model to simulate the damping at the end.
box2d is an open source project that provides a great 2d physics engine.
this library is used by Intel clutter, which is a nice physics oriented UI library that is capable of running on mobile devices. that means that box2d is already optimized for mobile platforms like the iphone.
I am developing a game in which i have to move the ball and power up image simultaneously.
For move a power up image view, I create a separate thread and call move method of power by using [self performSelectorOnMainThread:..], this is required to show the updated position on view. But my Game slowdown after creating this thread.
please guide me in improving the performance of game.
You probably don't want to be creating your own thread here; that's probably slower than doing this work on the main thread unless your calculations are incredibly complicated.
Instead of creating your own threads, investigate CoreAnimation. It's designed to handled moving things around smoothly, manages its own threads transparently, and provides a "fire-and-forget" interface. For most 2D games, the first approach you should follow is CALayers for each element moved around using CoreAnimation.
We didn't design or write your game so how can we be expected to know how to magically fix it for you? Do some research of your own, use Apple's excellent "Instruments" and "Shark" tools for tracking down the problem(s).
I strongly suggest you look at cocos2d instead of manually managing sprites and graphics. Cocos2d will abstract all of that stuff away from you.