High CPU Usage

0 favourites
  • 13 posts
From the Asset Store
High Low is a casino game using luck and points accumulation.
  • Hi

    So I made something today, however it has high CPU usage. Here is the source file:

    https://www.dropbox.com/s/ap2hxpqlqoic2 ... .capx?dl=0

    (The code is messy and is not well written)

    Is there a more efficient way to do what i was trying to achieve?

  • First, if you have performance problems. Put the events in groups, the less events in one group the better. Then check the CPU-Usage in the Profile-Tab in the Debug-Layout

    Your performance problem is the function call. You're calling the function from a loop and in the function there is another loop. You have up to 250 sprites and for each sprite you call the function, which is going again trough all sprites. That's an a amount of up to 62500 loops in one tick! (1/60 sec).

    I made a little change, don't know if that's still exactly what you want, but you will see I only check 2 sprites a tick, that will be call the function. So this are only 500 loops a tick.

    The change in the function you can ignore, it was only a test and it seems you're gaining nothing from this change.

    I hope I could explain this well enough, sorry for bad english.

    https://drive.google.com/uc?export=down ... TdYaFM2aHc

  • Debug mode's profiler says that event sheet 1 is all of the high% CPU utilization here. That should give you a hint of where the CPU usage is being drawn from.

    You have multiple culprits here, apparently, which are:

    *Your "Repeat 100 times" loop

    *Your A function

    *Your For Each SpriteFamily event-chain

    All of these are draining about 50-70% in increased CPU usage, so you may want to improve them or find ways of doing this without constantly polling Construct 2 repeatedly. (i.e, per tick stuff, repeat x times, etc)

  • Yes i know what the problem is. The loop inside the function makes the problem and that is why because i couldnt find a better way to compare the distance of each instance of a same sprite with other instances. So the whole idea is to create a line sprite if 2 instances are closer than 50 pixels with each other. So is there any better way to check the distance of each two instances?

  • First, if you have performance problems. Put the events in groups, the less events in one group the better. Then check the CPU-Usage in the Profile-Tab in the Debug-Layout

    Your performance problem is the function call. You're calling the function from a loop and in the function there is another loop. You have up to 250 sprites and for each sprite you call the function, which is going again trough all sprites. That's an a amount of up to 62500 loops in one tick! (1/60 sec).

    I made a little change, don't know if that's still exactly what you want, but you will see I only check 2 sprites a tick, that will be call the function. So this are only 500 loops a tick.

    The change in the function you can ignore, it was only a test and it seems you're gaining nothing from this change.

    I hope I could explain this well enough, sorry for bad english.

    https://drive.google.com/uc?export=down ... TdYaFM2aHc

    Your code works but it has a problem. A Square can only connect to one square at a time, but I want squares to connect to all the squares that are in the distance of 50 or less pixels

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • HessamoddinS

    That was only an example that you have to split up your nested loops.

    You have to look how many sprites you have to check every tick. You can do this with a repeat loop:

    You have to try how many loops you need. The 10 is only a guess.

  • Asmodean ok thanks i will look into it

  • HessamoddinS

    You got me curious, so I tried a completely different approach...

    instead of comparing every sprite to every other sprite, I used a larger sprite "detector" to find sprites within 50px of the active sprite.

    plus I found a number of other ways to reduce the work it has to do every tick:

    • only look for close sprites 4 times a second
    • simplified the dictionary look-up
    • only calculate distance once per line per tick
    • don't update the text object every tick

    now it hits 60 fps, and averages around 15 to 20% cpu

    you can take a look at my code here: http://www.rieperts.com/games/forum/DotEffect.capx

    Then I though it would be fun to make one sprite "sick" and see how long it takes to spread. So, press x on the keyboard to turn a random sprite red, then any time it connects to another sprite, that one gets infected and turns red too. (it doesn't take very long!)

    press the space bar to turn them all back to black. (And then press x again to start another wave of zombie sprites)

  • AllanR Thanks that was really helpful, I learned a lot

    The thing is I was trying to implement this effect in the background to the game I'm working on and I had plan to use a lot more than 100 sprites on the screen, which i think would not be possible. I just hope there was a more efficient way that could handle around 300 objects.

  • HessamoddinS

    I beleive that this is what you want to do.

    https://www.dropbox.com/s/2bxe5qcl3v8oq ... .capx?dl=0

    Runs like a slow poke in the debugger.

    Runs at 118 FPS on my laptop, outside the debugger.

    I like the idea of using a dictionary to keep the amount of lines as low as possible.

    But, then you gots to use the the dictonary's feature to not allow the same key twice. Look at how i solved that.

    Have fun.

    Edit: AllanR, did not see your last capx yet. Had this topic open while coding, so topic was not refreshed when posting this¨.

  • 99Instances2Go ha, we were definitely thinking along the same lines. You must have a really nice laptop!

    HessamoddinS

    I just added another optimization that I was thinking about adding to the first version - limiting how many sprites it checks per tick.

    this version bumps the sprite count up to 300, but only checks 5 per tick. So, it takes a whole second for them all to have a turn looking for connections - but because there are so many, most of them will already have the connection made to them. Since it checks the same number every tick, there is no jerkiness.

    it runs very smoothly on my computer, cpu is under 50% as reported by C2 (but Windows says it really is only about 27%). If you watch really closely you can occasionally see where a connection should have been made but didn't get checked in time. But since there are so many other connections going on, I doubt anyone would ever notice.

    http://www.rieperts.com/games/forum/DotEffect2.capx

    if you play with the SpriteCount and CheckPerTick variables, keep SpriteCount an even multiple of CheckPerTick, otherwise some will never get checked, or it may even go into an infinite loop or something...

  • HessamoddinS

    I beleive that this is what you want to do.

    https://www.dropbox.com/s/2bxe5qcl3v8oq ... .capx?dl=0

    Runs like a slow poke in the debugger.

    Runs at 118 FPS on my laptop, outside the debugger.

    I like the idea of using a dictionary to keep the amount of lines as low as possible.

    But, then you gots to use the the dictonary's feature to not allow the same key twice. Look at how i solved that.

    Have fun.

    Edit: AllanR, did not see your last capx yet. Had this topic open while coding, so topic was not refreshed when posting this¨.

    Thank you, this is great. I think I have solved the problem of having the same key twice but it wasn't good.

    Really helpful Thank you guys this thread was great I learned a lot from your examples.

  • 99Instances2Go ha, we were definitely thinking along the same lines. You must have a really nice laptop!

    HessamoddinS

    I just added another optimization that I was thinking about adding to the first version - limiting how many sprites it checks per tick.

    this version bumps the sprite count up to 300, but only checks 5 per tick. So, it takes a whole second for them all to have a turn looking for connections - but because there are so many, most of them will already have the connection made to them. Since it checks the same number every tick, there is no jerkiness.

    it runs very smoothly on my computer, cpu is under 50% as reported by C2 (but Windows says it really is only about 27%). If you watch really closely you can occasionally see where a connection should have been made but didn't get checked in time. But since there are so many other connections going on, I doubt anyone would ever notice.

    http://www.rieperts.com/games/forum/DotEffect2.capx

    if you play with the SpriteCount and CheckPerTick variables, keep SpriteCount an even multiple of CheckPerTick, otherwise some will never get checked, or it may even go into an infinite loop or something...

    That's great. Thank you

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)