[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