{"author_name":"csanyk","cat":"LD #35","comments":[],"epoch":1461718200,"likes":1,"metadata":{"p_key":"5774","p_author":"csanyk","p_authorkey":"10473","p_urlkey":"41222","p_title":"Shape Struggle 1.1.0.6 post-compo: performance optimized","p_cat":"LD #35","p_event":"LD35","p_time":"1461718200","p_likes":"1","p_comments":"0","p_status":"UPD5","us_key":"10473","us_name":"csanyk","us_username":"\/author\/csanyk\/","event_start":"1460678400","event_key":"33","event_name":"LD35"},"text":"

 <\/p>\n

I’ve gone over the code for Shape Struggle, and optimized it for performance \u00a0On my machine, I can’t get it to drop frames in the latest post-compo build, 1.1.0.6. \u00a0The thing is, my laptop is pretty high-end (2.8GHz Xeon E3-1505M, 64GB RAM), so I’m not sure how well it runs on older machines… I need testers!<\/p>\n

>>> Play and Rate Shape Struggle <<<<\/a><\/h2>\n

I figure my optimization tricks might help other developers, so in brief, here’s how I did it:<\/p>\n

    \n
  1. Controller object: \u00a0I knew even before the compo ended that I needed to set up a controller object to optimize the performance of the up to 500 instances of oEnemy that I’d have active in the game. \u00a0But the code in the controller object from the 1.0 build was far from optimized. \u00a0I refactored and streamlined the code, eliminating redundant conditional checks, and pulling code out of loops to make them as tight as possible.\n

    I also pulled some Step event code out of the two most complex objects, oSquare an oPentagon, and put it into the controller object. \u00a0Doing so enabled me to write some of the code in the controller so that it runs once for all instances of oSquare and oPentagon, rather than once per<\/em> instance. \u00a0 This makes a huge<\/em> difference in the amount of calculations necessary when there are hundreds of instances active. \u00a0No matter how many there are, there’s only one calculation performed.<\/li>\n

  2. Simplified bullet object. \u00a0At maximum firepower, the player fires 5 bullets per shot, one shot every three steps. \u00a0At 60fps, that’s 100 bullets per second. \u00a0That’s 100 creation events per second. \u00a0I thought I should limit the number of bullets, and also I wanted to limit the range of the player’s weapon, so I put a timer in the bullet object that destroyed the bullet instance after 1 second.\n

    Potentially, I might have optimized this by implementing object pooling, so that rather than creating and destroying bullets, I would re-use the instances so I wouldn’t need to keep creating and destroying them. \u00a0But first, I tried removing the timer, and found that the game plays and feels exactly the same, so that timer code doesn’t matter. \u00a0Normally setting a variable and then decrementing it doesn’t take a lot of CPU. \u00a0But with up to 100 fewer creation events every second, and 100 fewer timers to decrement every step, it adds up.<\/p>\n

    Object pooling might yield still more performance optimization, but simplifying the objects as much as possible first before making such efforts is smart.<\/li>\n

  3. I also removed the collision check from the bullet object that checks for collisions with the wall, and put it in the wall. There’s only 8 wall instances, so 8 collision checks vs. up to 100 each step means a substantial savings in calculations.<\/li>\n <\/ol>\n \n

    Tags: csanyk<\/a>, LD35<\/a>, Optimization<\/a>, post-compo<\/a>, Shape Struggle<\/a><\/p>","time":"April 26th, 2016 7:50 pm","title":"Shape Struggle 1.1.0.6 post-compo: performance optimized"}