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.
Related
Im trying to get my head around the render pipeline on a Head Mounted Display.
Given that a we have a target refresh rate of 90hz per screen.
Is there efficiency built within the pipeline that benefit from a reduced compute load on the reduced delta from one frame to another in VR?
Im wondering does the fact that less pixels have changed in the image from Frame A to B # 90fps compared to Frame A to B # 45fps given the same movement on screen.
I.e is the workload per frame from moving 1 frame to another anyway reduced by these new frames.
http://imgur.com/6rRiWGM
AFAIK all frames on VR HMDs are always rendered from scratch as in other 3d applications. If there was a good method to magically interpolate the rendering why would it only be used on VR?
There is however another trick called Timewarp. With proper async timewarp implementation if you don't provide a new frame in time, the last one is rotated by the delta of your headset rotation.
So when you look around, the head movement is still looking as if your
app would have high fps.
If you were not moving and there is nothing "stuck" to the camera like a GUI, this is a very good ilusion.
Currently timewarp is working well on GearVR and Vive, possibly on production ready Oculus (but not on DK2 on 0.8 drivers, still haven't got my new headset).
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
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've been noticing lately that my game sometimes has performance issues, where each frame takes a lot longer than it should to finish. I plugged it into the CPU Sampler in Instruments and found something pretty strange (I think, this is my first time using CPU Sampler so I don't understand all of it).
glClear is apparently taking up an insane amount of CPU time (it currently reads 36%, and is steadily rising). This is a fairly processor-heavy game, so there is no way one call to glClear should be taking up so much time.
glClearColor(backgroundcolor[0], backgroundcolor[1], backgroundcolor[2], 1);
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
This is only called once per frame. I don't have an active stencil buffer, so that's not the problem. One thing that might be problematic is that my game allows you to move off virtually as far as you want in any direction, meaning that your x and y location can get very far from the origin. Does glClear try to clear the entire landscape you've covered or does it only clear the dimensions of the screen? And if that's not a problem, than does anyone know why it is being so expensive on my processor?
glClear is waiting on the rest of your commands to complete (which, afaik on iOS means vsync?).
If you
glFlush();
glFinish();
at the end of your rendering, you'll see a lot of the time spent in glClear move to glFinish.
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.