Game Development Reference
In-Depth Information
private function onEnterFrame(e:Event):void
{
dispatchEvent(new CustomEvent(CustomEvent.UPDATE));
}
//EXAMPLE #2
//CALLBACK GETS SET THROUGH A PUBLIC ACCESSOR
private var _updateCallback:Function;
public function set updateCallback(value:Function):void
{
_updateCallback = value;
}
//ENTER FRAME HANDLER CALLS METHOD INSTEAD OF DISPATCHING EVENT
private function onEnterFrame(e:Event):void
{
_updateCallback(someData);
}
The first example makes use of an event dispatched every single
frame, which is taxing. Instead, if there is only one recipient for the
update event, it is more efficient to simply call a method. As men-
tioned earlier regarding the depth of display list, this is not likely to be
a huge issue for games, but it is an area you can look to for optimiza-
tion if you find the performance of your application a little lacking.
A Question of Balance: Inheritance versus
Interfaces
As you
ve no doubt seen throughout this topic, one of the key ele-
ments to writing modular, re-usable code is to make use of inter-
faces. The heavy usage of these interfaces can be seen in examples
in Chapters 13 and 14. Because of the AOT compiler for iOS and
how it allocates memory for each method, interfaces perform more
slowly than directly referring to an instance of a class. In other
words, see the below example:
'
protected var _boardImage:ISourceImage;
var imageData:Vector.
<
BitmapData
>
= _boardImage.getImages
(_rows, _columns);
would perform more slowly than this:
protected var _boardImage:SourceImage;
var imageData:Vector. < BitmapData > = _boardImage.getImages
(_rows, _columns);
This is because an interface just represents how something
works rather than the thing by itself, Flash always has to look up
Search Nedrilad ::




Custom Search