Profiling Gideros games and performance

stetso

Hi everyone,

I am currently stuck with my game. It runs buttersmooth in the desktop player but creeps along at unplayable fps when testing with the Android player (note to self: start testing on mobile earlier next time...). I dont seem to have a memory leak as memory usage behaves as it should. Since I ran out of ideas on where to optimize and the game reached a level of complexity where it is difficult to show anything specific and ask for help (also, I would not know what to show...), my question is a little bit broader:

How to profile a Gideros game? I would like to know on which function(s) time is spent. Do you know any libraries, self-made solutions or black magic for that? Any hints on how to get some insights are appreciated :-)

The thing is that the game should not be particularly taxing. There are not many sprites so it surely has to do with me.

Thanks!

hgy29

I think you can start by looking here: http://lua-users.org/wiki/ProfilingLuaCode

Yan

My way is to reverse disable:

1st disabe particle and other fx, try fps
2nd disable object sprites, try
3nd disable all level objects obe by one and look for fps, some actors may down fps in some tiny places of code
4th disable big backgrouds, specially when it transparent PNG, and more specially if it more than one

this is the 1st steps, if fps still low - check your code for big loops through tables - drops fps as hell.

antix

@stetso, so what kind of things are happening in your main loop?

NatWobble

@stetso

There are some good suggestions above. Here are some more optimisation ideas:
1) As Yan says, large areas of transparency in sprites and backgrounds are a real FPS killer. For example, a common mistake is to make a border frame from one sprite with a large transparent window in the middle. Try making composite objects of smaller sprites.
2) Draw calls. If you have a lot of sprites layered on top of each other, each requires a draw call, which uses GPU time. Try to minimise this. We still try to stick to a maximum of 3 going back to the days when we made HTML games (although Gideros has better performance and we could probably have a few more nowadays).
3) If you use background sprites then set stage:setClearColorBuffer(false) to save a draw call behind the background every frame.
4) Don't use very large backgrounds. If your game is scrolling etc, design it so the background is made of smaller sprites and try to reuse those images.
5) Pool your objects. Have a pool of enemies etc that you disable somewhere off screen, place them back in the pool when they die and then reuse them.
6) If you are doing any large calculations (using nested loops etc), that you can do that at the start of your scene in advance, then do it in advance. Show a short loading message.
7) Preload the sounds you need in advance.
8) Use RenderTarget sparingly. It's quite GPU intensive. If you can just create PNGs in advance, then do that, or try to rethink or compromise on how you can achieve the effect you want.
9) If you are trying to support multiple languages with different character sets, separate them.
10) The more complex your polygons are with path2D, the more they will affect performance.

pie

My 2 cents to integrate NatWobble post
11) wherever possible use ipairs or a standard for loop instead of pairs (which is slower)
12) try to avoid nested loops
13) localize everything you can: functions and vars
14) if possible use multiplications instead of divisions (20*0.5 should be faster than 20/2)

totebo

Without these things I couldn't make the game I'm making now:

- Pooling and reusing objects
- Local variables instead of self or global wherever possible
- Callbacks instead of events whenever possible
- Caching font glyphs

This also helps performance:

- Particles instead of sprites wherever possible
- Macros instead of global constants

keszegh

@totebo, can you explain briefly (or provide a link) how to use callbacks instead of events? thanks

totebo

Check out the code a few posts down in this thread:

http://giderosmobile.com/forum/discussion/6477/creating-and-dispatching-event-more-efficiently/p1

Still using CallbackBroadcaster for all custom events. If I used normal events the game would grind to a halt.

keszegh

thanks @totebo for the explanation. it seems that callbacks are essentially the same as events from the usage point of view and also i have the impression that the implementation must be also similar. this makes me wonder how can it be faster than events which theoretically do the same, just in native code.

totebo

Tell me about it! It's the same thing exactly usage wise. But much, much faster. Not sure why.

keszegh

@totebo, in this case you could even redefine event related built-in functions and this way replace the built in event handling with your implementation, making it easy for everyone to improve running speed.

stetso

Wow, thank you all for your input. I really appreciate it. Unfortunately I wont have time to dig into the problem over the next days but as soon as I will find a minute, I try to figure out whats wrong with all you help. Thanks a lot!!!

(from a first glance, my main suspects are the events and pooling... will need to investigate...)

keszegh

@stetso, " I try to figure out whats wrong with all your help" - that's a good one.

HubertRonald

Hi @stetso

Don't forget than Undeclared variables are always global, in Lua
You can try the following code:

local function globalVariable() for k,v in pairs(_G) do print(k,v) end end   globalVariable()   MyClass = Core.class() function MyClass:init() local x = 3 -- lowercase X = x+1 -- uppercase (for this case: It's a typing mistake intentional "X" instead of "x")   end   NClass = MyClass.new() NClass = nil print(""); globalVariable()   --print report: "X = 4" is a global variable.

Sometimes this can generate memory leaks when change the scene

Also, I use to check the memory leaks, this script (attached it, because I don't remember its link download)

totebo

Hey @keszegh, that would be super-neat. Any idea of how to overwrite the built in events to use callbacks? Especially interested in TOUCHES_MOVE and ENTER_FRAME.

keszegh

@totebo, of course i've meant only to replace user created events this way. i don't think you can avoid using system events, as there is no other way to get the same information.

on the other hand you can use your handlers for system events such that e.g. only one enter_frame is listened to and that calls back all other enter_frame functions, the same for touches etc. could be done.