Update: I have since abandoned this project in favor of the PushButton Engine, which wraps Box2D and provides a better graphics and component set than I could hope to achieve on my own. So far this has served as a useful academic exercise, and I will keep the code here for future reference.
The Setup
For those not in the know, Box2D is an open source 2D physics engine for C++. There are many ports of it, and luckily there’s one for AS3 (Box2DFlashAS3). The current version (2.0.2) looks very similar to the C++ version, and might be a straight port (I’m not entirely sure). It follows the C++ syntax of class prefixes and allows public access to (what should be) internal member variables. 2.1 promises cleaned up syntax and fixed accessor types, but until then, the library can seem daunting to the uninitiated.
The Problem
The main problem is that Box2D doesn’t define a (reusable) way to graphically represent objects on the screen. It only simulates the interactions between the objects mathematically. This is very efficient, but not very convenient if you need to rapidly prototype a physics based application. There are tools to build Box2D worlds for the Flash environment, but they emphasize working within the Flash IDE. I hate and loathe the Flash IDE (not AS3 projects themselves, mind you). I want something tailored for Flex. I want something that fits into the rapid application development cycle of most Flex apps, which means I want to use MXML. I want to stay up to date with the Box2D project, so when 2.1 does roll around, I won’t have to rewrite application code.
The Solution
Enter FlexWorld. FlexWorld is a framework for graphical representation of Box2D bodies. It is most similar to the World Construction Kit, but is meant exclusively for Flex. You get all the benefits of Flex, including the LayoutManager, styles, events, data binding, and MXML.
The Demo
FlexWorld Demo (launches in a new window)
How it Works
FlexWorld starts with a PhysicalWorld, which is a subclass of Container. PhysicalWorld has boundaries determined by its width and height. Children of the PhysicalWorld are typically subclasses of the abstract class PhysicalBody (which extends UIComponent). Right now, only the PhysicalBox and PhysicalCircle classes are available. World initialization happens only when you say it does, and clean up is as efficient as can be. To get going, initialize the world: PhysicalWorld#createWorld. Then, you can register each PhysicalBody with the world by calling PhysicalWorld#registerBody. This is to ensure proper instantiation and update. When the world is ready to go, just call PhysicalWorld#activate, and it will start rendering.
In-Phase updates
PhysicalWorld renders by calling PhysicalBody#update on each PhysicalBody registered with it. This render cycle falls into the commitProperties phase of the component lifecycle (more on that here and here). This ensures that properties are changed at the beginning of the lifecycle, just before commits will happen. If the render is meant to continue, updateDisplayList (which is at the end of the update cycle) will call UIComponent#invalidateProperties on the PhysicalWorld.
Where is this going
This is a very alpha release. Everything that you see works, and not much else. The shapes aren’t interactive yet, and they don’t do much drawing beyond what you see. Nothing is documented (and I’m horrible at keeping up with it), I don’t even have an SVN repository set up yet. Right now it’s primarily an interesting proof-of-concept rather than a useful tool. I’ll be developing it more for a project I’m currently on, and hopefully I’ll roll those changes in.
The Source
The source for the demo is here.
The source for the library (including Box2DFlashAS3 2.0.2) is here.
Can’t wait to see the latest version up here! Might be fun for playing with FXG too?
Jon,
It’s come a long way since last week and I’m currently in the process of refactoring it to use 100% interfaces. All the classes that are representative of bodies will no longer be view components. The only object required to be a VC is the world, after that everything is either a controller for bitmapData (will be much faster) or a controller for an mx or fx component. In essence, you could write a subclass of mx/fx List that implements IWorld, and suddenly all the itemRenderers are conforming to parameters of the physical world. :)