I'm developing a 2D game on iOS, but I'm finding it difficult getting drawing to run fast (60 FPS on Retina display).
I've first used UIKit for drawing, which is of course not suitable for a game. I coulnd't draw a couple of sprites without slowdown.
Then I moved on to OpenGL, because I read it's the closest I can get to the GPU (which I think it means it's the fastest possible). I was using glDrawArrays(). When I ran it on the Simulator, FPS dropped when I was reaching over 200 triangles. People said it was because the Simulator or the computer are not optimized to run iOS OpenGL. Then I tested it on a real device, and to my surprise, the performance difference was really small. It still couldn't run that few triangles smoothly - and I know other games on iOS use a lot more polygons, shaders, 3D graphics, etc.
When I ran it through Instruments to check OpenGL performance, it told me I could speed it up by using VBOs. So I rewrote my code to use VBO instead, updating all vertices each frame. Performance increased very little, and I still can't surpass 200 triangles at consistent 60 FPS. And that is 2D drawing alone without context changes/transformations. I also didn't write the game yet - there are no objects making no CPU-intensive tasks.
Everyone I ask says OpenGL is top performance. What could I possibly be doing wrong? I am assuming OpenGL can handle LOTS of polygons that are updated each frame - is that right? Which method other games use that I see they run fine, like Infinity Blade which is 3D, or even Angry Birds which has lots of ever-updating sprites? What is recommended when making a game?
OpenGL is definitely going to be your fastest option. Even on the oldest iOS devices you can run about 20,000 polygons at 30+ fps.
Sounds like you must be doing something wrong or extra. It is impossible to try to guess what that might be without seeing your source code.
Generally speaking though, you want to make sure you create your VBO and all your loading outside of your drawing pipeline.
Related
I'm currently making an app for an assessment which generates a maze using Recursive Backtracking. It's a 25x25 grid maze, with each wall being a separate SKSpriteNode (I read up that using SKShapeNodes was not efficient).
However, there are about 1300 nodes in the scene, which is causing some frame rate issues, even on my iPhone X. It's currently idling at about 15-30 fps, which really isn't ideal.
Are there any ideas on how to either cache SKSpriteNodes to produce better performance? I'm probably overlooking many things, and not creating walls in the most efficient way but the frames seem way too low to be correct?
If anyone would be able to suggest or nudge me in the right location that would be a huge help.
I highly recommend using SKTextures for repeated, identical images. See Creating a Textured Sprite Node.
For optimal performance, create sprites before compile time and put them in a texture atlas in your asset catalog. For creating texture atlases, see the documentation for SKTextureAtlas.
Ok so I'd like to place a large number of skspritenodes on screen. In the game I'm working on and even in the sample twirling spaceship game the cpu usage runs high in the simulator. I'm not sure how to test my game on an actual device (unless I submit to apple) but I'd like to know whether having something like 50-100 nodes on screen would use too much CPU time.
I've tested putting out large numbers of skspritenodes and the cpu usage reads 90% or more. Is this normal? Will I get laughed at if I hand Apple this game based on the extremely high (and growing) amount of CPU usage for this game?
Lastly, is there a way to avoid lagging during different points in the game? Arching? Preloading textures? idk, something like that.
Performance results seen in simulator are not relevant at all. If you are interested in real results, then you should test on different devices.
From the docs:
Rendering performance of OpenGL ES in Simulator has no relation to the
performance of OpenGL ES on an actual device. Simulator provides an
optimized software rasterizer that takes advantage of the
vector-processing capabilities of your Macintosh computer. As a
result, your OpenGL ES code may run faster or slower in iOS simulator
(depending on your computer and what you are drawing) than on an
actual device. Always profile and optimize your drawing code on a real
device, and never assume that Simulator reflects real-world
performance.
On the other hand, SpriteKit is capable to render a hundreds of sprites at 60fps if you are using texture atlases to draw many nodes in a single draw pass. Read more here.
About preloading textures into memory you can check :
Preload Texture Atlas Data section
and
+ preloadTextureAtlases:withCompletionHandler: method.
Hope this helps.
I am new to Objective-C and OpenGL, so please be patient.
I'm building an app that is mainly based on a full-screen 2D pixelbuffer that is filled and animated using mathematical formulas (similar to fractals), mostly using sin, cos, atan etc.
I have already optimized sin and cos by using tables which gave quite an fps boost, however, while the framerate is cool in the Simulator on a Mac Mini (around 30 fps), I get a totally ridiculous 5 fps on an actual device (iPad Mini non-retina).
As I see no further ways to optimize the pixel loops, would it be possible to implement the effects using, say, an OpenGL shader, and then just draw a fullscreen quad with a texture on it?
As I said, the effects are really simple and just iterate over all pixels in a nested x/y loop and use basic math and trig functions. The way I blit to the screen is already optimal for the device while staying in non-OpenGL, and gives like a million FPS if I leave out the actual math.
Thanks!
If you implement this as a OpenGL shader you will get a rediculously massive increase in performance. The shader would run on the graphics chip, which is designed to be massively parallel, and is optimized exactly for this kind of math.
You don't make a texture so much as define a shader for the surface. Your shader code would be invoked for every rendered pixel on that surface.
I would start by trying to see if you can hack a shader here: http://glsl.heroku.com/
Once you have something working, you can research how to get an OpenGL context working with your shader on iOS, and you shouldn't have to change the actual shader much to get it working.
I hear a lot that power of 2 textures are better for performance reasons, but I couldn't find enough solid information about if it's a problem when using XNA. Most of my textures have random dimensions and I don't see much of a problem, but maybe VS profiler doesn't show that.
In general, pow 2 textures are better. But most graphics cards should allow non pow 2 textures with a minimal loss of performance. However, if you use XNA reach profile, only pow 2 textures are allowed. And some small graphics cards only support the reach profile.
XNA is really a layer built on top of DirectX. So any performance guidelines that goes for that will also apply for anything using XNA.
The VS profiler also won't really apply to the graphics specific things you are doing. That will need to be profiled separately by some tool that can check how the graphic card itself is doing. If the graphics card is struggling it won't show up as a high resource usage on your CPU, but rather as a slow rendering speed.
I have several fundamental questions to clearify to myself, hope you'll help...
I'm developing a game application. It has game loop and on each iteration i draw about 200 sprites. What is the fastest way of drawing bitmap? Currently I use [UIImage drawAtPoint] method to draw a sprite (sprite sizes can be 16x16 ... 64x64), but something tells me, this is not the best approach. As I understand, UIImage is based on Quartz technology? Can cocos2d provide the better performance?
I also thought about using OpenGL ES to reproduce drawing mechanism via textured objects.
If you're making a game you'll probably want to avoid Quartz/UIKit/CoreAnimation. They're designed to be simple and easy to use, at the cost of performance.
Opengl is the fastest way to draw sprites to the screen on the iPhone. There are two versions of Opengl in iOS: OpenglES 1.1 and OpenglES 2.0. If you're looking to support the iphone 3G and earlier, you'll need to either use 1.1 exclusively, or be able to determine the device you're running on and switch versions on the fly. Opengl is very fast but at the cost of a fairly steep learning curve and a lot of what you'd see as boilerplate code.
Cocos2d is an iOS game engine built on top of Opengl. It's designed to make using opengl easier (among many other things). If you're making a game, I'd suggest you use cocos2d as they've done a lot of the hard work already. If you don't you'll be spending 99% of your time getting opengl to work, rather than focusing on the game.
Good luck! :)