In part 2, we looked at an example of performing imageProcessing in a seperate thread.
In this final installment, I’ll show how you can run your Physics entirely on a seperate thread, and we’ll also throw in a little Starling to the mix as some icing on the cake
Here’s an example of what we’re making:
As a comparison, here’s an optimized Haxe Demo rendered in CPU mode with Physics done in the main thread:
http://deltaluca.me.uk/docnew/swf/StressPyramid.html
On most computers the single threaded test will struggle to reach >45fps. With the CPU completely maxed out. Even if you do manage to hit 60fps because you have a super fast CPU, you;re still totally maxed out, you would have no more room at all to do anything else in your game. Contrast that to the Worker implementation, where the main thread is doing virtually nothing on the CPU. It spends <1ms on de-serializing the data, and a couple more pushing a bunch of vertex's to Starling. It has so much free time it's taking a smoke break!
Overview
First a quick overview of how this will work:- The Nape simulation will live entirely inside a Worker thread
- The Main Thread will make calls on the Worker Thread when it wants to add a new Physics Body
- Each frame, the Worker Thread will copy the position data of all bodies into a shared ByteArray
- The Main Thread will read the position data from the ByteArray, and use it to update the on-screen Sprites
Document Class
The first step is to setup our worker and some message channels so we can talk.At this point you should be familiar with this boiler-plate code for a Worker-based application: [...]
Read more: Intro to AS3 Workers (Part 3): NAPE Physics + Starling!
No comments:
Post a Comment