This week I'm going to be moving back from architecture and camera development to the physics systems again. I'm working over a way to use air resistance to help make the game's logic a bit more internally consistent.
In the meantime, you may recall that I talked about Flash coordinate systems very briefly last week. The tricky thing when doing conversions is figuring out just how little Flash cares about what's done to its parent clip. I want to reiterate that principle this week and give some specific instances where that's likely to bite you.
For example, if you resize a movie clip in Flash, the internal coordinate system of that clip stays exactly the same. That means if you're doing conversions manually, you need to multiply all of your final values by the scale.
Rotation is another point where Flash doesn't care - a rotated movie clip will internally have no change in it's coordinate system whatsoever. This can, again, lead to problems if you rotate an object with a lot of children by 90 degrees - when referencing that object's children, your x axis and y axis will be switched, because the children don't know that they've been rotated.
The best way I know of to think about this stuff is to imagine a parent clip as a lens for its children. The parent clip can be manipulated in a number of ways, and that manipulation will show itself in the children. But the children themselves are never manipulated. They just look like they have been, because they're being viewed through the lens of the parent clip.
This is another reason why localToGlobal is so ridiculously useful. It worries about that stuff for you. I can't emphasize enough how much time you can save by using those functions instead of doing the math yourself.
No comments:
Post a Comment