Day 4: Flash Collision and its Limits

Today was another day to get my hands dirty with Flash and working with ActionScript 3. Unfortunately, the professor was a bit quick with going over Flash, and I felt I may have only skimmed over very important aspects; however, I did manage to figure out how to save a drawn image as a class and make a movement animation using that image. This led to this horrendous-looking figure here, which I refer to as "QuestionOnion":

The figure in question, once drawn, also has a peculiar shape; in previous collisions involving 2D sprites, it was sufficient to use rectangles and circles for proper and quick collision. For such an object like this, such complexity required not just a convex hull (mind you, impossible with a sprite without set point information) but a bitmap pixel collision test.  How this is done is that the figure's transform matrix, along with its bounds is used to setup a bitmap, which is then compared with a hitTest function to the other figure. If the pixel overlap is a color other than a clear nothingness, then spot-on collision is achieved. This is problematic due to the inefficiency of checking each pixel, but EXTREMELY problematic that no other collision actually works in that regard for drawn sprites like this. If I ever use any prototyping involving complex hulls, I must make it clear that the figure's points must be taken into account, if at all. That, or subdivided simple collision sprites (circle for the body, box for the stem).

On the bright side, it was made very clear to us that a manager class would be best for checking inputs (in the case of changing mapping of values), and I created an InputManager class in case such use would be required in later projects involving Flash.