Printable View
I created a platformer on Android, but scrolling the level very much affects the FPS (on medium and weak devices). Levels use obstacles (Active objects) and backgrounds (Backdrop objects and Quick backdrops). This problem manifests itself precisely during the runtime of Android.
How can this be prevented or corrected? The game is too simple to be so slow..
How large are your quick backdrops? That’s probably part of the issue. Android really needs graphics to fit within the power of 2 rule. Once we know the size of your quick backdrops, we can go from there.
I have divided the background into 600x700 squares. But I have level without big backdrops, only platforms and small backgrounds in the form of walls, divided into squares 163x146 and there the game is slow too.Quote:
Originally Posted by piscesdreams
hi, I had discussed this with a guy who was programming a platform game, I think it can help you
https://community.clickteam.com/threads/107410-Need-some-help-testing-FPS-on-different-Android-devices
One thing that comes to my mind is, maybe if you use physics, try in the physicsObjectProperties to uncheck; - add backdrop objects to the world - create projectiles in the physical world - insert non physical objects in the world. From my experience it makes big difference, especially if you have a lot big non physical actives backdrops etc.
You are right, but unfortunately I need non-physical objects and backdrops, since I use them as a obstacles. I unchecked the bullets onlyQuote:
Originally Posted by Manuel
If you have a physics object uncheck everything just for a test and put it on your phone and look at the fps closely, so you know for sure it is not the issue, i had the same issue in the past for me it was.
Thank you, Manuel, I was able to slightly raise the FPS. But overall, it’s still slow. Perhaps due to the number of active-obstacles (400-1800)
On Android I'd advise you 'delete created backdrops at' when they scroll offscreen, and similarly recycle active objects as much as you can. It may require a re-implementation of your scrolling system, however.
Your images of 163x146 are rounding up to the next power and using the memory equivalent of a 256x256 image. It may help to slice these down into images of smaller powers of 2. Unfortunately the difference would be an image of 35x18, which would use the equivalent of 64x32 in memory for that also. You would need to slice it down into smaller parameters so it isn't using extra memory.
The image of 600x700 is using the equivalent of 1024x1024 worth of memory. You would need to do a 512x512 image and then the difference in smaller images to optimize performance and RAM a bit.