[haXe] APE port.

[lee at designrealm.co.uk]

Excellent, Hugh. Well done! I'd love to see those demos when your done.

Lee






Quoting Hugh Sanderson <haxelist at gamehaxe.com>:

> 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
>>
>
>
>
> -- 
> haXe - an open source web programming language
> http://haxe.org