about the debugger

I'm trying hard to optimize my (goddamn) game, as it's running at sluggish 20 fps on phones. I know Scirra's policy is "measure it yourself" so that's what I'm trying to do, but I find it (boring and fustrating as fu--) difficult for a number of reasons. No, only one reason actually: ignorance. Mine.

So I open the debugger, and there I'm basically looking (Watching) at:

FPS obviously,

Est. CPU utilisation,

Collision checks per sec,

Poly check per sec.

I also have me a big tileset, of which I'm overseeing the Draw and Collision rects... and then the global CPU performance on the Profile Tab, to see if any loop has gone wild.

Obvious question: is there anything else I should be keeping an eye on?

(Not like I'm like, blind to anything else, but yknow).

Also. I feel like I lack references, beyond the 60 fps. I'm aware my question here might just miss some abstract technical element at its base that make it unanswerable or something (i really know but very little about devices), but i'm gonna try anyway: is there any reference values I can hang to for things as... well, as those listed above-- CPU, collisions, polygons? Which range of values are mobile-safe for polygon checks, for example?

I guess (and it's a guess) that those values may depend heavily on the machine you are working on... so lets say for your average, win10 good ol laptop? -- just like mine? ;P

Thank u guys

Hey Mega,

Hopefully you have your event sheets sorted out and have things placed into groups, if so the profile view will show you how much of your cpu is being taken up by each group. Look for the big %'s first, does it make sense that X group is using that much?

Can things be optimised in that folder? When you disable groups of code does the fps spike up?

You are right that there is no safe values due to the wildly dif specs of devices, you just want to keep things as low as possible on what you have.

Things that will likely be killing your performance are unnecessary everytick events.

If everything is fairly optimised code-wise, see how things go when you strip out some assets. Could be you are getting gpu bottlenecked.

GenkiGenga cheers mate, thanks for your answer. Yeah I think my problems are mainly code issues. Me and my loops! Im placing triggerOnces everywhere I see fit, and so on. My graphic assets are all png8, which I hope makes it all faster, as well as lighter.

Glad to say I made some improvement. I had some "proximity checkboxes" placed in a parallax 0 layer, which was no good for C2 collision cell sysytem (i was gettin like thousands of checks per tick -- now I'm around 20-40!). Game is quite playable now , though still slower than intended (some 40 fps). My objective is not less than the damn 60fps on phone. Is that a realistic goal for a big layout game? Is that... really necessary, too? I mean, do commercial mobile games (not AAA games, just fine games) stick to the 60...? Right I know you can't get universal 60fps , but -- should I definitely try to achieve them in my own (mid-end) phone? Guess wont be an absolute answer, but what you guys think?

Did you turn on render cells in layer properties?

After 30FPS your eyes won't be able to tell the difference so its a goal you shoot for but not exactly hit every time. I made a tutorial that will help you alot here

newt yes -- in some layers at least. Says the contxt help it's for "large layers with many static objects", so used it on "tileset" and "invisible-platforms" layers, both with default 100% parallax... or should i just turn it on on all layers and be damned?

PixelPower sweet man, I'm having a look right now! thnk you for that!

"or should i just turn it on on all layers?"

You could try, but I doubt it will help much.

The only other suggestion would be to check your collision filtering.

Like if you have a lot of instances checking if they collide with a much fewer amount of some other object.

That leads to a bunch of unneeded checks.

Always try to set the order to fewest first.

No worries mate. Your graphics being smaller size wize affects the download speed but once they are loaded into your game its all the same unfortunately.

I think most mobile games go for 30fps - playable. I am a bit the same, anything under 60fps doesnt feel right to me either but I wouldnt strive for it. Not for mobiles anyway. Things are always improving and getting faster but in general my approach is to just choose a baseline dev device and go up from there. If you're getting 40 fps on your mid range phone I would say it's pretty good.

Not sure how big your layouts are but If I was you I would do a test with your assets. Disable your current code and have a simple event that just scrolls the layout. If you are getting 60 fps then perhaps you can refine your code, if you are still getting around 40 then it is probably not worth it.

thank you brothers, you're being of huge help. I have me game in a pretty advanced state, and suddenly discovering that it was near unplayable on phone came quite as a low blow -- yeah i know, but testing on mobile is such a drag, never was able to setup the lan for preview.

GenkiGenga hey that's a good idea. I disabled all events, leaving just a few behaviours. Still need to try it on phone (drag) and study the measures closer, but there's a noticeable difference in cpu usage. Well I am slowly rearranging code blocks according to newt 's Laws ;P dude there's stuff for a great tutorial in the last bunch of answers youv been giving me these last days! What you just said in that last post about the collision order for example, is just the kind of thing one just dont knows (gotta say i had most of my conditions wrongly set, according to that!), and it's also revealing of how C2 (js even) works. thank you so much!

I'll let you guys know how i fare