Before we dive in, there’s something you should be aware of:

This code exists because it’s easier for me to prototype new things in ActionScript. That being said, there are certainly opportunities to improve performance and structure but I’m not interested in doing that here. I’ll address those issues and share the result when I port it over to my target platform in C#.

I’ve taken time to try and make things as easy as possible to use. I’m assuming you’re reading this because you need to leverage this functionality and want things to “just work”.

Here it is:

// create a vector of points that express the first polygon.
var points1:Vector.<Point> = new Vector.<Point>();
points1.push(new Point(0, 0));
points1.push(new Point(50, 0));
points1.push(new Point(50, 50));
points1.push(new Point(0, 50));

// create the first polygon, adjust it's registration point and move it.
var polygon1:Polygon = new Polygon(points);
polygon1.offset = new Vector2D(polygon1.center.x, polygon1.center.y);
polygon1.translate(new Vector2D(50, 50));

// create a vector of points that express the second polygon.
var points2:Vector.<Point> = new Vector.<Point>();
points2.push(new Point(0, 0));
points2.push(new Point(100, 0));
points2.push(new Point(100, 100));
points2.push(new Point(0, 100));

// create the second polygon, adjust it's registration point and move it.
var polygon2:Polygon = new Polygon(points);
polygon2.offset = new Vector2D(polygon2.center.x, polygon2.center.y);
polygon2.translate(new Vector2D(200, 200));

At this point, there are two polygons ready to shake, rattle or roll. When you’d like to see whether or not they’re colliding, use the following:

// define a container to hold a translation vector that can be altered by the collision.
var collisionResponseTranslation:Vector2D = new Vector2D();

// finally, discover whether or not a collision has occurred.
if(polygon1.isCollidingWith(polygon2, collisionResponseTranslation))
    polygon1.translate(collisionResponseTranslation);

That’s it! Here’s a demo that illustrates things a little better:

Please keep in mind that this will only work for convex polygons. My game doesn’t merit getting as complex as the folks at Metanet did with N so until it that time, it’s pretty much complete.

You’ll find the demo and library source, here.

Good luck and happy coding!

Anyway, it’s not serving the community sitting around my hard drive so I went ahead and pushed it up to the vim script repository.

http://www.vim.org/scripts/script.php?script_id=2478

Hopefully, it will make someone happy.

It’s been months since my last post (and coincidentally changing jobs) but I’d recently dusted off a grid-less rendering engine for 2d games and was slightly disgusted with it core. It’s really not that bad. It works but the main loop gets a wee-bit lengthy and burns up cycles evaluating items that could possible be out of context at any given moment.

Using function pointers to create a state machine wraps this up nicely. Cheers, Squize!

This kind of reasoning was satisfying in the beginning but as I gain more experience with component development in Flex, I’m finding that it may not be as clear cut as I once thought. In fact, it wasn’t until I glanced at this article on Adobe’s Developer Connection site that I’ve since refined my decision-making process.

Here are the two points mentioned in the article:

• When you create composite controls declaratively, MXML makes it easier to create and lay out child controls.
• When you modify the behavior of components, that is, override their methods, you typically use ActionScript.

As simple and obvious as they may sound, they’re quite powerful when trying to decide in which direction to take your development. As stated in the article, most of the time you’ll be using a combination of the two. One way to do that is by using a technique called “code behind” which is something I’m working on right now…

UPDATE: After playing with the code behind technique mentioned in the article it seems obvious to me that it’s the way to go in most cases. It’s also very satisfying to separate form from function in a sensible manner.  Unless, you’re developing a very simple component you should probably get in the habit of writing core logic (as a class) in ActionScript and extending it via the root tag in MXML.

Well, I totally forgot about this (too good to be true?) until today, when Ted Patrick announced that indeed, development is still moving forward in this area.

I’ve been chewing on the thought of creating P2P clients in AIR but couldn’t figure out an elegant approach to packaging a client module (written in ActionScript) and a server module (written in C/C++, Java or Python) in a single AIR installer…

Could this be it?

It’s free, GPL’d, has excellent documentation and just plain works. On top of all that, there’s even a full-fledged ActionScript 3 Client API available!

While working through the tutorials I found myself writing more than one flash client and decided I’d be better off distilling them down to a single template. I think it’s a decent starting point for those “Hello World” demos and could potentially become the base for a full-blown, multi-user client application.

You can download the files, here.

Please let me know if you’re working on a Flash client for an SGS application. I’d love to hear about it!

For anyone familiar with Grant’s implementation, you’ll notice the method signature is similar.

To determine whether or not the bitmap data values of two display objects are “colliding”, you simply call:

var x:Rectangle = Collision.collisionTest(myObj, yourObj);

Alternatively, you may also pass a third argument representing the alpha tolerance which in turn gets passed to the alphaTolerance argument of the ColorTransform constructor.

var x:Rectangle = Collision.collisionTest(myObj, yourObj, alphaTol);

You can see an example, here or download the Class definition, here.