[haXe] APE port.

Hugh Sanderson haxelist at gamehaxe.com
Sat Dec 1 14:34:43 CET 2007


Hi,
I have ported the haXe/swf port of the APE engine to neko/nme on windows.
I ported the code by defining a compatability layer, I called "blink",
where you basically replace the classes "flash." with "blink.".
I only did enough to get the demos going, but I think this shows
the viabliity of this method.  More about this on
http://gamehaxe.com/2007/12/01/cross-platform-again/

The neko code took about twice as long for the numeric stuff, but
this may have to do with the "cast" operator.  I will try
to get a more game-like example going and see what the performance
is like with a bunch of image draws.

Hugh


> Hi all.
> I have ported the Actionscript Physics Engine (APE,  
> http://www.cove.org/ape) to haxe.
> The performace is comparable, except for the "cast" operator, which I  
> replaced in one case for extra speed.
> See: http://gamehaxe.com/ for more details.
> It is basically a line-for-line conversion done with a bunch of  
> reg-exes, which worked surprisingly well.
> Also perhaps of interest is the fact the by writing a program to do the  
> conversion you get a list of things different between as3 and haxe.
>
> For one case, there was practically no change in speed. For another,  
> there was a 20% slowdown (I suspect it may have to do with casts too).
> In both cases, the hx->swf was faster than hx->as3->swf.
> The haxe compile was considerably faster than the as3 compile.
>
> The change list included:
>
>   - Convert “int”, “void”, “Number” etc.
>   - Convert “package xxx {” to “package xxx;”.
>   - Expand out “import xxx.*” imports.
>   - Remove “private”, “final”, “internal” etc.
>   - Scan the class for “get” and “set” functions and insert “var  
> prop(get,set):type” where appropriate. This was complicated by the fact  
> that some of these were “override”
> properties and should not have this extra insertion. (I should have  
> looked for the “override” keyword to make this easier).
>   - Add return statements to set functions.
>   - Fix POSITIVE_INFINITY.
>   - Make sure arrays are strongly typed - need this for properties.
>   - Change in-line array declarations when array is not of type Dynamic.
>   - Convert “indexOf” function in array.
>   - Convert “for(a ;b ;c )” to “a; while(b) { … c }”.
>   - Fix scoping of variables resulting from variables declared inside  
> for statements.
>   - Add semi-columns to lines that needed them.
>   - Change constructors to “new”.
>   - Add static main function to main class, and “addChild” it.
>   - Call “super()” where required.
>   - Convert default-arguments to optional-arguments.
>   - Remove “break” from switch statements.
>   - Change “is” and “as” operators.
>
> Generally, I prefer haxe's way of doing things.  However, there is some  
> syntactic sugar that would be nice too.
> 1. The alternate form of the "for" statement. It would be nice to have  
> both.
> 2. "indexOf" - I think there may be room for 1 extra function in the  
> base class.
> 3. The "get" and "set" function specifiers.  I think the as3 way is  
> slightly better, since it is more localised and I'm not a big fan of the  
> haxe syntax.
>
> Calling your constructor "new" and requiring an explict call to super()  
> I'm undecided which it better.  I guess its hard to detect when super is  
> called if it is in, say, a conditional.
>
> Another little option to save some typing might be to have a  
> "-main-class ClassName" as an alternative to "-main ClassName", where  
> the former just automatically creates a static main function that simply  
> "new"s the class.
>
> Hugh
>





More information about the Haxe mailing list