Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Android / Performance Problems

Author
Message
Mig
10
Years of Service
User Offline
Joined: 25th Feb 2014
Location:
Posted: 25th Feb 2014 08:01
Link
Hey guys,

we are new with agk and stuck a bit with the development. The language is clear and we are able to build amazing things quickly, but our main problem is the performance.

We tried to make a simple side scroller where the player has to avoid to collide with objects, get powerups and so on.

As soon as we tested our software on real android devices, we faced the bitter truth. the frame rate is ok on high-end devices (some slowdowns are recognizable) but on low end or midrange devices the game is simply unplayable.

We tried many things like removing the scrolling background images, increasing or decreasing the image size by the power of 2, remove transparent effects if it’s not absolutely necessary and switching to lower resolutions like 320x240, but nothing seems to effect the performance in a satisfying way.

At first we managed the objects to get randomly created to block the path of the player and get removed as soon as they were out of screen and recreated again in front of the player.

Performance was aweful. Then we tried to build the whole level at the beginning of the game and set the view offset according to the players position (that speed up things a little, but still far from a playable version of the game).

In most cases, we did not have more than 10 sprites on screen simultaniously, none of it larger than 128px x 128px.
What's the trick to increase frame rate and avoid frame rate dropping?
We use the online service to build our apk´s.

Thanks in advance.

404 - signature not found
Back to top
Profile PM
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 25th Feb 2014 09:00
Link
All of the things you have done should help. There's no reason why a game like this wouldn't run well. One thing we don't know is how you've coded the logic (and how experienced you are with coding, so forgive me if I am telling you things you already know)

You may not want to share your code, in which case you'll need to benchmark different parts of your code to see where the bottlenecks are. Even on a high-spec system you can test by displaying the frame rate, and comparing it as you add and remove the different parts of your code.

ten-net consulting limited
Back to top
Profile PM Email
Mig
10
Years of Service
User Offline
Joined: 25th Feb 2014
Location:
Posted: 25th Feb 2014 15:21 Edited at: 25th Feb 2014 22:27
Link
Hi,

thank you for your quick reply! We will post part of the source code later!

404 - signature not found
Back to top
Profile PM
SirCodeALot
10
Years of Service
User Offline
Joined: 25th Feb 2014
Location:
Posted: 25th Feb 2014 15:31 Edited at: 25th Feb 2014 22:25
Link
TEST
Back to top
Profile PM
Mig
10
Years of Service
User Offline
Joined: 25th Feb 2014
Location:
Posted: 26th Feb 2014 08:11
Link
Hey guys,

in order to get more specific help we figured it would help to make our code available for download. So here is a striped down version. No playable thing, just moving sprites. But also included is an apk file to directly run it on a test device.

It runs well on a Sony Experia Z (Android 4.3), has some lags on a Huawer G510 (Android 4.1.1), has a very low framerate on a Acer V360 (Android 4.1.1) and is unplayable on a Sony Xperia Pro (unknown android version).
Any feedback would be very much appreciated.

Especially reports about tests on actual devices woud be helpful.
So maybe someone could take a look at it.

Thanks!

404 - signature not found

Attachments

Login to view attachments
Back to top
Profile PM
Funnell7
13
Years of Service
User Offline
Joined: 8th Sep 2011
Location: UK, England
Posted: 27th Feb 2014 16:34
Link
The biggest issue with performance is generally the fill rate, I'm yet to experiance any significant slow down as a result of the code itself (I have hundreds of collision checks, loads of raycasts, lots and lots of physics etc etc).

Looking at your example, you don't seem to have an issue with either of these, so I suspect this is just a device limitaion with AGK. Have you tried running a simple 'hello world' app with perhaps 1 full screen sprite? What FPS do you get then?

Just for reference, I tried the APK on my Samsung S4 and got a steady ~60 FPS...
Back to top
Profile PM Email
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 27th Feb 2014 16:48
Link
There's no obvious issues in the code you provided. On my desktop it's running at 2,700 FPS

ten-net consulting limited
Back to top
Profile PM Email
29 games
18
Years of Service
User Offline
Joined: 23rd Nov 2005
Location: not entirely sure
Posted: 27th Feb 2014 18:47
Link
Hi

I've just run the APK on my Arnova 7h G3, which is seriously low spec (single core, 512 mb ram), with Android 4.0.3 and I'm getting 59 fps. I'd be happy with that.

I noticed that some of your image sizes are not in powers of 2, BGPic.png for instance is 144x256, this might be causing some issues.

With the cloud images, would it better to load it in as a single large atlas image rather than 4 small ones?

I also noticed with the clouds that your deleting and creating sprites during the game loop. I was under the impression that creating and deleting any media slowed things up but I could be wrong about that.

Have you tried running the Rush To Adventure Pre Alpha (see the showcase board) on any of the devices you've had problems with? It runs great on my Arnova and might give you an indication if it AppGameKit or your app that is the issue.

Purple Complex: An Arcade Style First Person Tactical Shooter - full game available now

[WIP] Hover Car Race Challenge Accepted! - NaGaCreMo 2014 project wip thread
Back to top
Profile PM Email
SirCodeALot
10
Years of Service
User Offline
Joined: 25th Feb 2014
Location:
Posted: 27th Feb 2014 18:59
Link
First of all thank you BatVink and Funnell7 for the quick reply and for testing our app.

Unfortunately our range of test devices is very limited for now. Though on most phones we were experiencing some, lets call it " global stuttering of moving objects" instead of an actual frame drop.

As an example:

device:

Huawei G510 (Android 4.1.1)

Frames:

steady at 33 Fps

Problem:

all moving objects stutter simultaniously every 1-2 seconds. Frame rate is stable and number and speed of objects doesn't seem to have any impact on the lags.

Regarding my observations and the positiv test run by BatVink and Funnel7 I assume the problem might be device/AGK related.

greetings

Sir-Kot-A-Lot
Back to top
Profile PM
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 27th Feb 2014 19:20
Link
The last time I had stuttering in an app it was caused by resizing large arrays. It may be something unrelated to the screen like this.

ten-net consulting limited
Back to top
Profile PM Email
The Daddy
15
Years of Service
User Offline
Joined: 13th Jan 2009
Location: Essex
Posted: 27th Feb 2014 20:49
Link
I have not looked at your code (too busy ATM), but smooth scrolling should be achievable on devices with android gingerbread up?

As suggested above
1) ensure image dims are a power of two
2) use atlas textures for animation rather than several images
3) make sure you are not creating / destroying objects (sprites / images) within the loop, create these before the main loop, recycle sprites ie. when an object flys off the screen, set its position to the other side of the screen, change the image it uses (already loaded prior to loop) and hey presto new flying object!...save creating loads of sprites hence saves memory also!
4) make sure you are not rendering sprites that cannot be seen (inactive/invisible etc)

Basically keep the scrolling logic TIGHT, even on faster devices. It is not only good practice but gives you room for adding to the scrolling maps if you have <spare> FPS, ie animated tiles, layers etc.

Good luck....this reminds me if the C64....scrolling was time precious and really always should be!

www.bitmanip.com
All the juicy you could ever dream of!
Back to top
Profile PM Email Website
Blendman
10
Years of Service
User Offline
Joined: 17th Feb 2014
Location: Arkeos
Posted: 28th Feb 2014 09:59
Link
Hi

I have test on my phone, and it works fine.

samsung galaxy trend (Gt -S7560) / android 4.04 :
59/60 fps

Just an little "error".
When I touch the back button, I have your message "We hope to see you soon!" just 500 ms and even if I don't touch the "ok" button, the game close.

http://www.dracaena-studio.com
Back to top
Profile PM Website
Naphier
14
Years of Service
User Offline
Joined: 2nd Oct 2010
Location: St Petersburg, Florida
Posted: 28th Feb 2014 22:25
Link
I suspect this is an issue with your frame rate adjustment.
I use
ft# = GetFrameTime()
SetSpriteX(spriteID , speed# * 60.0 * ft#)

Napland Games Facebook Twitter
Back to top
Profile PM Email Website
SirCodeALot
10
Years of Service
User Offline
Joined: 25th Feb 2014
Location:
Posted: 1st Mar 2014 11:02
Link
Hello again,

wow guys I am truly amazed by the participation and all the helpful hints we got from you. We really appreciate it.

So far we did/tried out:

Set sprite visibility if in/out screen

Avoided the destruction/creation of cloud sprites

Set new images into sprites

payed our respects to the power of two

changed the frame rate adjustment as sugguested by Naphir

set frame rate to 40 (first 60, then 30, didn't work as well as 40)


coming up:

atlas textures

moving sprites only when on screen


With the changes we did so far we experienced a huge change in performance especially on older/less powerful devices.

For newer devices there is no visible lag or stuttering to be noticed.

With some of the older phones there was only a little stuttering left. Still noticeable but playable.

Even on my Huawei it was running kinda smooth.

We will keep you updated about the process of the developement.

Thanks again guys this really helped a lot.


Kind regards Sir Kot A Lot
Back to top
Profile PM
SirCodeALot
10
Years of Service
User Offline
Joined: 25th Feb 2014
Location:
Posted: 4th Mar 2014 08:28
Link
Hello once more,

we are busy finalising our project and looking forward to launch by the end of this month.

Regarding the performance, the power of 2 and transparency I have another question I can't find an answer to.

Lets say we have a simple image 64x64. The actual visible object in this image is only about 40x52 (just as an example)and the remaining pixels are transparent.

Now to the question.

1. Does transparancy in images affect the performance in a bad way?
(we felt like it does)

2. If so, how do you avoid this situation?


I was thinking about splitting the image in several smaller images
and merge them somehow or let them move together in a group,
though I can imagine that it looks strange during lags/stuttering.

Looking forward to hear your thoughs about this.

Kind regards

Sir Kot A Lot
Back to top
Profile PM
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 4th Mar 2014 08:40
Link
Somebody will need to verify this but I think the "square image" concept is this...

You should load the image as a power of two image.
Once loaded you can grab different parts of the image for use in the game

I think it's all about loading it into graphic memory as a power of two, but after that you do whatever you like with it.

ten-net consulting limited
Back to top
Profile PM Email
Naphier
14
Years of Service
User Offline
Joined: 2nd Oct 2010
Location: St Petersburg, Florida
Posted: 4th Mar 2014 09:00
Link
You can find lots of info on this topic and endless debates. From what I've ever understood is that power of 2 textures are easier for the GPU to calculate scaling for.
Performance issues with transparent images start to happen when you have many overlaps of transparency.
Most devices should be able to handle a fairly large number of sprites without much issue. The easiest way to find out is by writing simple tests. Load sprites and move them randomly and observe frame rate.
Once you start using sprite collision shapes or physics is where you start to see the bigger performance drops.
Always try things out with some simple tests to benchmark devices and see where you need to make tradeoffs.

Napland Games Facebook Twitter
Back to top
Profile PM Email Website
Kevin Picone
22
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 5th Mar 2014 05:26 Edited at: 5th Mar 2014 06:14
Link
renders prefer powers of 2, so that each texel fetch can be bit shifted rather than needing a multiply per pixel for an arbitrary width.

pseudo basic styled code for fetching from the texture

Texel= PeekInteger(TextureAddress+( V * TextureModulo ) +(U << 2))

if TextureModulo is a power of 2 though, like say 256, then you can just shift V.

Texel= PeekInteger(TextureAddress+( V<<8) +(U << 2))


Convert PlayBASIC To Machine Code
Back to top
Profile PM Website
29 games
18
Years of Service
User Offline
Joined: 23rd Nov 2005
Location: not entirely sure
Posted: 6th Mar 2014 17:48
Link
Glad to see you're making some progress.

Images do not have to be square, just as long as the height and width are a power of two.

Yes, transparency does affect performance but "in a bad way" is somewhat subjective. There's some more advice in the "development tips" in the help files.

I think what you need to do is put as much as you can on a single image (of whatever size but keeping it less than 1024x1024) and then create a sub-image to grab different bits of it for use with the sprites.

Purple Complex: An Arcade Style First Person Tactical Shooter - full game available now
Hover Car Race Challenge Accepted! - full game available now
Back to top
Profile PM Email
Clonkex
Forum Vice President
14
Years of Service
User Offline
Joined: 20th May 2010
Location: Northern Tablelands, NSW, Australia
Posted: 24th Mar 2014 02:20
Link
Quote: "wow guys I am truly amazed by the participation and all the helpful hints we got from you. We really appreciate it."


Aside from wanting to help, I think we also all want to prove AppGameKit is a really good language

Quote: "With the changes we did so far we experienced a huge change in performance especially on older/less powerful devices."


Excellent, glad to hear it

Quote: "2. If so, how do you avoid this situation?"


When I make games I try to design it so everything revolves around using power-of-2 images; ie., design it so the scale of everything fits well in power-of-2 images. Otherwise, there isn't really a way around it. Generally, though, most devices should handle at least several hundred sprites on screen at once, depending if they are using the same image or not (sprites of the same image will be automatically batched).


Placement Editor Professional -- Code Line Counter -- Tiled TMX Map Loader 2.0
Open Bezier Curve Library -- Image Tools
Back to top
Profile PM Email
Back to top

Login to post a reply

Server time is: 2024-11-09 00:32:50
Your offset time is: 2024-11-09 00:32:50