Skip to first unread message
Vasco
Aug 20, 2014, 8:02:01 PM8/20/14
to
Usually the performance bottleneck on iOS is related to rendering/fillrate, but from my tests it seems to be from simple code logic. I am testing on an iPod Touch 4.
I am making an extremely simple game, which has about 80 50x50 sprites. If I do nothing to these sprites, the game runs easily at 60 fps.
But if on each update() frame, I try to do something simple to each of them, like change their velocity depending on their position and checking to see if they're onscreen, the framerate drops to about 50fps. I've tried doing this by iterating through the sprites from the PlayState (they are in a FlxTypedGroup), and I've tried extending FlxSprite and adding the logic there (instead of iterating), with the same result.
As another example, there's a point in the game where I run FlxG.collide between 30 sprites (all colliding with each other), and the framerate drops to about 30fps! Just due to the collision logic. If I remove the collisions but keep the sprites the framerate doesn't drop. I realize that colliding 30 sprites corresponds to 900 collision tests, but surely the iPod 4's 800 MHz processor should be able to handle that? The 2.66Ghz processor on my PC can handle 1000 sprites colliding with each other at 60fps (1000000 collision tests), in Flash. And I've developed for iOS before with Cocos2d, and always had lots of processor power to spare (the real issue was always the fillrate).
Are there any known performance issues on iOS, or something I can do to improve performance? Thanks.
I am making an extremely simple game, which has about 80 50x50 sprites. If I do nothing to these sprites, the game runs easily at 60 fps.
But if on each update() frame, I try to do something simple to each of them, like change their velocity depending on their position and checking to see if they're onscreen, the framerate drops to about 50fps. I've tried doing this by iterating through the sprites from the PlayState (they are in a FlxTypedGroup), and I've tried extending FlxSprite and adding the logic there (instead of iterating), with the same result.
As another example, there's a point in the game where I run FlxG.collide between 30 sprites (all colliding with each other), and the framerate drops to about 30fps! Just due to the collision logic. If I remove the collisions but keep the sprites the framerate doesn't drop. I realize that colliding 30 sprites corresponds to 900 collision tests, but surely the iPod 4's 800 MHz processor should be able to handle that? The 2.66Ghz processor on my PC can handle 1000 sprites colliding with each other at 60fps (1000000 collision tests), in Flash. And I've developed for iOS before with Cocos2d, and always had lots of processor power to spare (the real issue was always the fillrate).
Are there any known performance issues on iOS, or something I can do to improve performance? Thanks.
Jonathan Hirz
Aug 21, 2014, 12:37:43 AM8/21/14
to haxef...@googlegroups.com
Are you grouping your sprites before collision checking?
SruloArt
Aug 21, 2014, 5:52:24 AM8/21/14
to haxef...@googlegroups.com
You should probably first test one of Flixel's collisions demos on your device to make sure this isn't just a problem with your code...
Vasco
Aug 22, 2014, 4:44:46 PM8/22/14
to
Jonathan: I wasn't grouping all of them, after grouping them I got an improvement of about 3fps, which is better than nothing but doesn't really solve the problem.
SruloArt: I tried running the FlxCollisions demo on the iPod, and as expected, it starts at 60fps but the framerate quickly drops to 15fps in about 5 seconds, with about 50 objects on-screen.
It's as if all code runs really slow on iOS for some reason. It doesn't happen just with collisions; as I said before, just adding a bit of code to the update() function of about 80 sprites is enough to slow things down.
SruloArt: I tried running the FlxCollisions demo on the iPod, and as expected, it starts at 60fps but the framerate quickly drops to 15fps in about 5 seconds, with about 50 objects on-screen.
It's as if all code runs really slow on iOS for some reason. It doesn't happen just with collisions; as I said before, just adding a bit of code to the update() function of about 80 sprites is enough to slow things down.
Reply all
Reply to author
Forward
0 new messages