Comparison FPS between iOS Browser and CocoonJS

0 favourites
  • 8 posts
From the Asset Store
See how your Logical Resolution looks on different devices
  • Hi Guys, im working to get decent performance, i couldn't figure out how to improve performance in CocoonJS, please download this .capx, it's simple it has 13 events.

    Touch any blocks that you can destroy some blocks in diagonal, they fall blocks and it doesn't use Physics behavior.

    I had some weird results.

    iOS 6.1 Safari (iPod Touch 4): i get 15-22 FPS as average

    CocoonJS 1.3: i get 11-13 FPS as average, i felt like WTF i had no idea why we know CocoonJS can boost up the performance.

    If you think this event sheet from .capx isn't correct, i would be appreciated if you explain how to make a workaround.


  • Found your problem. I'm not sure how to fix it yet, but it's your falling block code. it's just killing performance by a massive amount.

    turning it off bumps fps back up to 62. However you obviously need it. I suggest figuring out a versio of block falling rest state.

    On blocks destroyed command.

    set all blocks to rest false

    if block rest = false, then drop.

    upon success of falling, block rest = true

    that way your not constantly causing the block checks to fall. i know you have the trigger once, but i don't think it's the appropriate usage.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Ok, what happened. C2 uses a brute force collision check. The block falling check was doing 2500(50x50 blocks) collision checks per tick. And no block managed to reach anykind of rest state

    oh, I got an idea. Give each block a Row/Col and a gotoX/Y variables. Upon deletion of block itterate each col(by for each ordered, block.col, descending) where blocks where destroyed. Assign the above blocks new Row and set a gotoY, and set falling = 1.

    then block.falling = 1 and block.y < block.gotoY

    -set position block.y = whatever

    -if block.y > block.gotoy

    -- block.y = block.gotoy,

    -- block.falling = 0

    I'm off too bed, but if I can help work on it tomorrow if you like :)

  • This test is definitely CPU-bound because of the 2500 collision checks per tick. CocoonJS only boosts renderer performance, not javascript performance, so you shouldn't expect to see better CocoonJS performance for this type of thing. You should definitely not to intensive collision checks like that every tick; try to run the checks only when the position of the blocks has changed.

  • ok, it's not done, but I think it's on the right track now :)

    What you need to finish up is to work on the "on Destroyed"

    Wher you need to itterate through all the current blocks above the missing ones. Set new gotoY and falling = 1. and the same for the new blocks.

    But the first set works 100% and maintains performance :) so the collision check problem is solved. Mainly because I removed it.

  • Ok, it would be collision check problem can affect the performance.

    If i couldn't figure out how to make a workaround to replace collision check to something like positions, it's WORST NIGHTMARE :S

    jayderyu honestly, you only removed collision but it doesn't solve to make it look like real falling blocks, i was thinking if could use compare 2 variables between another block position Y and block height, so i don't believe i will get resolved :S

  • Anyone could help me?

    I'm desperate :S

  • I posted a reward if you are interesed to help me.

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