[haXe] APE port.

[Hugh Sanderson]

Yes, that would be great.
I wonder if Dan is interested in merging with xinf too?
Although, it seems like that API is perhaps heading in
a different direction to the flash api, and accounts for js too,
so maybe it is too different.

I think it would be pretty easy to get together a bunch
of use cases/test code and get somewhere pretty fast.

I have some NME mods I would like to merge back in too,
so merge away.  We should set up a project somewhere.

Hugh


> Hey Hugh,
>
> Your demos are very impressive. I've been taking a look at your Blink  
> code, and I think you and I could collaborate some. I've started work on  
> a library I was going to call hxme, which wraps NME into Flash9 like  
> classes, so one could compile to Neko or Flash9 using the same code  
> base.  It currently includes methods for handling the display stack,  
> that would fit very nicely into your DisplayObject class. Would you mind  
> if I merged?
>
> Regards,
> Lee
>
>
>
>
>
> Quoting Hugh Sanderson <haxelist at gamehaxe.com>:
>
>> You can see the source and exes in:
>>
>> http://gamehaxe.com/wp-content/uploads/2007/12/blinkdemo.zip
>>
>> Hugh.
>>
>>> 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
>>>
>>>
>>>
>>> --
>>> haXe - an open source web programming language
>>> http://haxe.org
>>
>>
>>
>> --haXe - an open source web programming language
>> http://haxe.org
>
>
>
> --
> haXe - an open source web programming language
> http://haxe.org