All these engines work only with convex polygons, and in no way support concave polygons. They do however support more than one shape (or polygon) in each of their rigid bodies. This gives us the change to fake concave shapes by making multiple convex ones. But how do we convert from concave to convex?

I did a bit of a search around and heard about such things as Ear Clipping and Minimum Convex Decomposition. The second I could even find code for (http://www.cs.ubc.ca/spider/snoeyink/demos/convdecomp/MCDDemo.html) which was awesome, and in Java none the less. But alas, even with the help of this awesome Java to AS3 converter, I failed at getting it to work.

Then I stumbled upon a great post on the Box2D forums “Concave Polygon Decomposition in Flash“. Someone had converted an Ear Clipping example in Processsing to a JSFL tool. Sweet!

So between the two example I managed to cobble together some not too shabby AS3 classes, and an example app. I’m hoping to add this to our Box2D wrapper (more on that later) so we can easily draw concave polygons ASAP.

Have fun!

1/ You have a whole lot of duplicate code comipiled into your libraries, which will not be used (as when the lib is loaded any classes of the same name will not override the existing ones)

2/ It takes a bloody long time to compile your library (when it should be fast)

Solution:
The best way we have found to get around this is to create a empty classes, which work similar to intrinsics (but are totally empty -no functions, vars or imports), to replicate the base class.

Eg.
If in your application you have a class for example: 'sprites.enemies.Monster'
In your lib you will want to create an asset with identifier: 'Lib_Monster' and base class 'sprites.enemies.Monster'. Normally this would compile in the full Monster class and all its dependencies.

If you set up your lib.swf in a seperate folder to the application then create another class, lets call it a placeholder class, 'sprites.enemies.Monster' and just have it empty eg:

When it compiles the Lib_Monster will have the correct baseclass, but it will not include any code.

The trick is that, when the lib is loaded into your application the class 'sprites.enemies.Monster' will conflict. The application should have its own compiled version (the one with functionality) and when the lib loads in, it will ditch its version (the empty one) and adopt the existing (correct) version.

It only takes a few seconds to create the placeholder class for the library reference.

If you want to have the lib.fla in the same folder as the application, then you can even set up a different classpath for the lib. To do this go tot the publish settings and add a new classpath (eg. ./intrinsics). This path will be checked first for your placeholder class.

If for some crazzzy reason your classes arn't used (and so compiled) in the application (if you reference them with weak references), you will need to force them to be compiled in like this.

The simplest way is to just type its name:

PLAIN TEXT
Actionscript:




import sprites.Ball


 


public function init(){


   Ball;


   // Or for many at once


   (Ball,Dirt,Kid,People);


} 

Just simply typing the class type somwhere in your application will force it to compile in. Why is this of any use you may ask?

We use it for level building in games, where you have a generic component as a placeholder used in flash to lay out content/levels. Your Ball class for instance, might then simply build itself using externally loaded assets, and attach itself to the stage. It may not need to be referenced anywhere in the application, but is still compiled in.

I recently had this problem with a game, that when the frame rate lowered, cyclic "emitters" (ie creating bubbles underwater) would not be synced with the expeted speed of the game.

The solution. A setInterval and setTimeout that you can set using milliseconds (or frames if you want) and will be called at the expected number of frames. The only caviet with this approach is that it needs to be inited with the stage object, both so it can get an ENTER_FRAME event and the current FPS.

Example Use

Source

It makes use of "internal classes" which I had not heard about until recently. I'm finding them really good in some cases and have heard they are actually faster than using non-defined objects ie {x:0, y:10} as the compiler can make optimizations to them. The only thing you need to remember is that they must be defined outside your package - which can be counter-intuitive and a little confusing at first.