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?
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!
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! :(
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.
Have you tried profiling your game?
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.
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...
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. ;/
Might also be worth keeping the sprite size down...
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).....
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 :(
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
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.
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
It might be worth checking to make sure that your main program loop isn't doing anything inefficient or unnecessary first.
Quote from: bigsofty on 2012-Jul-17
Have you tried profiling your game?
I can't see any info in the GLB help about profiling, can you enlighten me as to how this is implemented and what exactly it does. Thanks in advance :)
This is very strange. JFG I'd be very interested to hear what turns up with your testing.
Also, Falstaff you mentioned those rendering errors and it looks like you have an Adreno GPU in your phone rather than the Mali-400 series (which seems to perform rather well on the S2). Does anyone have an S3 here that wasn't bought in North America? It should have a Mali GPU in that case.
Btw Crivens it seems crazy to me that sprite commands could ever be faster than the equivalent in polyvectors. I'd have to see it with my own eyes to believe it. :)
Quote from: Wampus on 2012-Nov-23
...
Btw Crivens it seems crazy to me that sprite commands could ever be faster than the equivalent in polyvectors. I'd have to see it with my own eyes to believe it. :)
It is a lot faster on the caanoo too, not that it has anything in common with an S3.
Well it's definitely the problem on my latest XCode 4.5 project. Even a single simple gradient significantly slowed down my app on an iPod 4th gen. It's important to note my last project used these sort of effects with no issues in XCode 3.2.
Cheers
...then it must be an apple feature! ;)
Heheh yeah. Seems ok on every other device. All I can think is XCode has changed things since 3.2 that significantly is slowing down my iPod touch when it comes to polyvectors. Everything else seems fine.
I just mentioned it as its a recent discovery of mine and it is worth testing both ways to make sure
Cheers
Colored poly vectors is pretty slow. Even a single font with few triangles slowdown too much. So it's a clearly bug somewhere. But flat polygons without using the last argument is not effected.
Mightbeen we should split the thread around gradient to bug section? It's might use some wrong format?
Quote from: spicypixel on 2012-Nov-23
Quote from: bigsofty on 2012-Jul-17
Have you tried profiling your game?
I can't see any info in the GLB help about profiling, can you enlighten me as to how this is implemented and what exactly it does. Thanks in advance :)
"Doh!", just noticed this, sorry for the slow reply.
You probably know this well by now Spicy but just in case...
Under the "Compiler" menu, click "Profiler" then "Active".
Run your code then exit.
Got back to "Profiler" then click on "Output".
The GLB editor will then open a tab with the profile.
I seem to easily loose track of threads in the forum. :(
BTW: The purpose of the profiler is to show how fast or slow your code is, split into a per subroutine list. It's an optimisation tool.
Quote from: bigsofty on 2012-Nov-25
Under the "Compiler" menu, click "Profiler" then "Active".
Run your code then exit.
Got back to "Profiler" then click on "Output".
The GLB editor will then open a tab with the profile.
Thank you :good:
Quote from: Ocean on 2012-Nov-25
Quote from: bigsofty on 2012-Jul-17
Have you tried profiling your game?
Like making backups, profiling is for cowards! :bed:
Beta testing too! :D
Coloured polyvector on egl is mostly very slow. I can't see a way to improve it. Try teinting the texture where possible.