Quick Links: Download Gideros Studio | Gideros Documentation | Gideros community chat | DONATE
Profiling Gideros games and performance — Gideros Forum

Profiling Gideros games and performance

stetsostetso Member
edited June 2017 in General questions
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!

Comments

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

    Likes: stetso

    +1 -1 (+1 / -0 )Share on Facebook
  • YanYan Member
    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.

    Likes: stetso

    vk.com/yan_alex
    +1 -1 (+1 / -0 )Share on Facebook
  • antixantix Member
    @stetso, so what kind of things are happening in your main loop?
  • @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.

    Likes: pie, stetso

    +1 -1 (+2 / -0 )Share on Facebook
  • piepie Member
    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)

    Likes: stetso

    +1 -1 (+1 / -0 )Share on Facebook
  • totebototebo Member
    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

    Likes: antix, stetso

    My Gideros games: www.totebo.com
    +1 -1 (+2 / -0 )Share on Facebook
  • @totebo, can you explain briefly (or provide a link) how to use callbacks instead of events? thanks
  • totebototebo Member
    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.
    My Gideros games: www.totebo.com
  • 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.
  • totebototebo Member
    Tell me about it! It's the same thing exactly usage wise. But much, much faster. Not sure why.
    My Gideros games: www.totebo.com
  • @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.
  • stetsostetso Member
    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...)
  • @stetso, " I try to figure out whats wrong with all your help" - that's a good one.
  • 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)



    lua
    lua
    monitor.lua
    3K

    Likes: MoKaLux

    +1 -1 (+1 / -0 )Share on Facebook
  • totebototebo Member
    edited June 2017
    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.
    My Gideros games: www.totebo.com
  • keszeghkeszegh Member
    edited June 2017
    @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.
Sign In or Register to comment.