Why is my game so slow on my new Galaxy S3 ?

[JFG]

Hello guys. First post here!

Here's the situation. I just got my new phone, the Galaxy S3. Nice phone by the way. I've been developing a new artillery game for some time now, everything works great on Windows and my Nexus S (solid 60 FPS). Now, on the other hand, the game runs fine on the S3, but really slowly. I barely get 20 FPS on it. Both phones are running ICS 4.0.4.

Everything is updated (GLBasic, S3 firmware, Android SDK). Everything else on the S3 is working correctly, and fast. Benchmarks results (Quadrant, Antutu, Nenamark) are good.

This is very disappointing. Any idea?
Help?

[Slydog]

If you are creating a 3D game, you may need to reduce the number of polygons in your models for a mobile platform.  Then try to reduce the number of material / texture changes and create multiple models that share the same texture file.

If it's a 2D game, are you using sprites?  If so, try switching to using POLYVECTORs.  This should help a bit if you use a fair number of sprites.  I'd advise using pure white (255,255,255) for all of the vertice colours, as I've read some mobile devices loose tons of FPS otherwise.

Put starting and ending log (DEBUG) statements (and include the current elapsed time) in each of your functions so you can see which functions are taking the longest, and start optimising the slowest functions.  If running on an Android, you should use STDOUT instead of DEBUG, and find out where that command sends the data.  People on here will know.
 
Anybody else know any other profiling tips?

[Edit] Oh, and BTW, welcome to the forums!

[JFG]

Thank you!

The game is purely 2D and I do use polyvectors almost exclusively. I'll try pure white only and see if it helps. One thing I tried last night was to skip different part of the game. For example, no sky, no background, no trees, which helped quite a bit. Conclusion is, calculations are done really fast and drawing to screen seems to be the bottleneck, which is odd as the S3 has way more horsepower under the hood, compared to the Nexus S.

I've also tried different games made with GLBasic directly from Google Play Store..  and.. they all run as expected. There's something in my game the phone doesn't like!

[erico]

There seems to be different supports for open gl on each and every android phone coming out.
I heard the galaxy range of phone, altough powerfull, have a few draw backs on the gl stuff.

All possible to go around I think.
Are you using grabscreen command?
How is collision going? calculating by hand or using a command for that?

Can you test exactly which part of the visuals that is actually holding things up?

I also heard polyvectors are faster when using a single map with everything and doing a single call.
Sorry I can´t help further as I have no android as of yet.

[bigsofty]

Have you tried profiling your game?

[JFG]

I don't use grabsprite or setscreen with Android, as advised.
I use boxcoll for collisions.

No profiling yet. I'll do more testing tonight if I can.
I feel the problem might be GPU related, as the game is silky smooth on the Nexus and is definitely not CPU intensive.
Thanks again guys for your help.

[mentalthink]

It´s a bit difficult help you whitout see a bit the code, but something you have wrong. I´m sure, I use Palm Pre for all testing, it´s very low category than galaxy, and my game have a lot of graphics, 3d textures at 1024x1024, ligth, sounds and physcis all combined and my game runs perfectly at 45 FPS, of course not are 60FPS, but 2D games not have too much problem in any game, and you are using boxcolls...

Perhaps this it´s obvious but, see if you are loading some image in the bucle, when you load in example a little image, like a jpg whit 60Kb, the game turn very very Slow... I told you because when I beggin whit glbasic sometimes occurs to me...

[bigsofty]

I'd still go for a quick profile though, even if some graphic command is not behaving itself on the GPU it's bad rendering time will still show up in the profile.

There's always the butcher method too, cut out bits, till it starts behaving, then examine the final previous bit. 

[MrTAToad]

Might also be worth keeping the sprite size down...

[spacefractal]

I guess S3 using 32bit surface, while Nexus use 16bit surface, but OpenGL driver is not optimized to run 32bit? I also guess benchmarks apps might just use 16bit which is pretty normal on Android. Also there is strange pageflipping issues on some systems which some times take a lots of MS, so try to massure your loop in MS to check what that use time. Is its CPU, GPU or SHOWSCREEN?

PS. Also I seen similar issue with HP Touchpad with Android, which run slowere than WebOS on the same tablet (hwovoer its a alpha version I using).....

[Falstaff]

I wonder if anyone else has had this problem? I just picked up an s3, and it's an awesome phone! My game runs like crap on it though.. I decided to check out the profiling, and it looks like it's the rendering that's taking all the time. I wonder what's up? I also noticed when I attached the adb log, the following error was being spammed in the logs, seemingly every frame:
E/Adreno200-EGL( 5919): <qeglDrvAPI_eglWaitNative:3113>: EGL_BAD_PARAMETER

I'm guessing maybe that has something to do with it, although I have no idea what it means.. google hasn't helped me much either. Hope it's something that can be addressed, was pretty excited to get this phone and it's pretty disappointing if my glb games won't run very well on it

[Crivens]

Are you using Polyvectors? If so then stop using them and try again.

The usual standard seems to be Polyvectors are faster, but something has changed recently it appears to me. I used randomising coloured Polyvectors to create a sort of animated plasma field in my old game and it worked fine with inertia scrolled text etc. No worries.

But now I'm making a business app in GLB and have faked a keyboard. One of things I did was use Gernot's posted routine to create rounded keyboard keys. Thats a lot of Polyvectors basically. I also used Polyvectors for producing gradients.

Anyway testing was going fine on Android with and S1, S2, and S3 phones. No worries. Plus WebOS was fine (Pre2 and TP). But when I moved to XCode it was as slow as hell.

I traced it down to where the keyboard was used and gradients. Remove the polyvectors and replace with sprites and it ran absolutely fine. I had noticed that on Android it was slightly slow but not too much to be worried about.

Note this was with with the last stable GLB (not 11 beta which I couldn't get to compile my old game in XCode) and the lastest XCode (4.5.something).

On a side note, the Polyvector gradient didn't look quite right either on Android (was fine on WebOS and iOS).

Cheers

[spacefractal]

Flat Polyvectors is faster and the heavy texture change in my game ran so much slower. So it's depend of project.

but yes, colored poly vectors can do slow down very much in some devices. Example for greedy mouse, they worked pretty nice on iOS 5 ipad 3, but slowed down on iOS 6, just like iPad 1 did. So I thinks it a driver issue here, or glbasic using some hidden windows, thread or such? But it's annoying. The why I looked by game to 30fps on those devices.

So yes, colored poly vectors should been keeps as minimum, but none colored poly vectors does render very nice and normally faster than sprites.

[Crivens]

I had a polyvector per keyboard key which were all completely black. Just replaced with a stretchsprite (for each key) and instead of really slow it's now fine. I also removed gradient polyvectors from a scrolling list of text (just used a single coloured rectangle instead) and instead of being really slow again it's all fine now.

Interestingly though I used a load of Polyvectors in my last game (with a similar scrolling list of text) and it was all fine. I'm thinking it's the latest XCode or something. And my old project doesn't seem to compile in the original XCode anymore (was 3.2 I believe) so I can't check it.

Personally overall I think with variations of Polyvector performance on different devices then I'll just keep to sprites. It's not as sexy and removes some functionality (eg. gradients although this doesn't seem to work correctly on the galaxy phones for me for some reaosn), plus maybe slightly slower in some cases, but seems to work with similar performance through a range of devices.

Cheers

[MrTAToad]

It might be worth checking to make sure that your main program loop isn't doing anything inefficient or unnecessary first.