I've got an iPhone game that is basically finished, but I have been spending some time profiling as I want to get the power usage down as low as possible, but I'm an OpenGL ES noob so I'm looking for some pointers.
The game is a fairly simple puzzle game, so 90% of the time the board is redrawing for no reason. At the moment I have a 'dirty' flag and only render anything if it is set, but then I draw everything, when most of the time only a tiny part of board needs updating (ie the timer, or one of the pieces).
Is there a common strategy to use with OpenGL for only updating parts of the screen, or does it assume that you want to redraw everything, all of the time?
Your application should wait until something in the scene changes before rendering a new frame. Core Animation caches the last image presented to the user and continues to display it until a new frame is presented.So you don't need to draw every time , just check for the update, and draw only when there is any update.
EDIT: For more details check opengl es programming guide-
here's [a link]http://developer.apple.com/library/ios/#documentation/3DDrawing/Conceptual/OpenGLES_ProgrammingGuide/Performance/Performance.html
Related
I'm currently using box2d with cocos2d on iPhone. I have quite a complex scene set up, and I want the end user to be able to record it as video as part of the app. I have implemented a recorder using the AVAssetWriter etc. and have managed to get it recording frames grabbed from OpenGL pixel data.
However, this video recording seems to a) slow down the app a bit, but more importantly b) only record a few frames per second at best.
This led me to the idea of rendering a Box2D scene, manually firing ticks and grabbing an image every tick. However, dt could be an issue here.
Just wondering if anyone has already done this, or if anyone has any better ideas?
A good solution I guess would be to use a screen recorder solution like ScreenFlow or similar...
I think your box2d is a good idea... however, you would want to used a fixed-time step. if you use dt the steps in the physics simulation will be to big, and box2d will be unstable and jittery.
http://gafferongames.com/game-physics/fix-your-timestep/
The frame rate will take a hit, but you'll get every frame. I don't think you'll be able to record every frame and still maintain a steady frame rate - that seems to be asking a lot of the hardware.
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.
I'm working on a relatively simple 2D side-scrolling iPhone game. The controls are tilt-based. I use OpenGL ES 1.1 for the graphics. The game state is updated at a rate of 30 Hz... And the drawing is updated at a rate of 30 fps (via NSTimer). The smoothness of the drawing is ok... But not quite as smooth as a game like iFighter. What can I do to improve the smoothness of the game?
Here are the potential issues I've briefly considered:
I'm varying the opacity of up to 15 "small" (20x20 pixels) textures at a time... Apparently varying the opacity in this manner can degrade drawing performance
I'm rendering at only 30 fps (via NSTimer)... Perhaps 2D games like iFighter are rendered at a higher frame rate?
Perhaps the game state could be updated at a faster rate? Note the acceleration vales are updated at 100 Hz... So I could potentially update part of the game state at 100 hz
All of my textures are PNG24... Perhaps PNG8 would help (due to smaller size etc)
It's really hard to debug graphics problems with this. Try using the openGL ES instruments to find where are the bottlenecks. It's quite handy. Also, look at the WWDC videos on openGL. They're really good.
One thing I noticed is that you said "I'm rendering at only 30 fps". Does it mean you're manually setting up a timer or something? This is not a good way, instead you should use CADisplayLink to get notified when the screen wants to update. It could improve your smoothness.
To complete Mo's answer on the 30fps...
The fact that you request the update at 30fps does not mean you're going to get it. I'm not an iphone programmer, but I can tell you that if your frame rendering takes 100ms, you're guaranteed to never update faster than 10fps. And if you're actually rendering at 10fps, then smoothness is gone.
So, measure the time you take to render to get an idea of what actual frame rate you get. As to how to optimize the rendering specifically for iphone, I'll leave that to people more expert than me on the subject.
I am building a 2d OpenGL es application For iPad it displays a background texture and numerous textures on top of it which are always in motion.
Every frame their location is recalculated based on time delta and speed and the entire thing is being rendered at 60 fps successfully, but still as the movement speed of the sprites raises, thing look stuttering.
Any ideas? Are there inherit problems with what I'm doing? Are there known design patterns for smooth animation?
Try to compute time delta as average of last N frames because it's possible to have some frames that take more time than others. Do you use time delta for animations? It is very important to use it! Also try to load all resources at loading time instead loading them when you use them. This also may slow some frames.
If you take a look at the time deltas, you'll probably find they're not very consistent frame-to-frame. This probably isn't because the frames are taking different amounts of time to render, it's just an artifact of the batched, pipelined nature of the GLES driver.
Try using some kind of moving average of the time deltas instead: http://en.wikipedia.org/wiki/Moving_average
Note that even though the time deltas you're observing in your application aren't very consistent, the fact that you're getting 60fps implies the frames are probably getting displayed at fixed intervals (I'm assuming you're getting one frame per display v-sync). What this means is that the delay between your application making GL calls and the resulting frame appearing on the display is changing. It's this change that you're trying to hide with a moving average.
im developing a 2d game on iphone in which i want to maginify the views on the screen to give the effect that the user is looking through the sniper whenever the user taps the screen..
i am required to show that the objects which the player wants to shoot should be moving...so im incremeting their position as well as increasing their size...
so i want this magnified image to show the updated positions of the moved objects at runtime to give the effect that the user is looking through the snpier...
scaling the images didnt help me cause it slowed my application a llot as the objects position is updated every 0.01 sec...
please help
Is it a 2d game, or are you using OpenGL ES? If the latter, you can always render your scene to a texture and use the hardware to scale that for you. That shouldn't slow down the game too much...
If 2d, it's always faster to scale one single image than a lot of individual objects, so here it also may be beneficial to render to an image first, and later scale and draw it on the screen.