DISQUS

Nicolas · 1 year ago

For imports, you can do the following

// Common.hx

#if flash9
typedef Bitmap = flash.display.Bitmap;
typedef BitmapData = flash.display.BitmapData;
....
#else neko
typedef Bitmap = noflash.Bitmap;
typedef BitmapData = flash.display.BitmapData;
...
#end

Then from your code you only need to "import Common".

The 115 Array Size is entirely arbitrary, it's just a temporary bugfix for a current Neko compiler issue that will be addressed in next version.

31 bit integers are part of the Neko specification (see http://nekovm.org). It's true that there is no crossplatform Int32 API right now, but that can easily be defined in haXe using inline methods.

James Urquhart · 1 year ago

Many thanks for the suggestions, Nicholas! :)

I'm surprised that i didn't figure that sticking the #ifdef'd stuff in Common.hx would be possible with haXe. Still, now i have an excuse to take a second look. :)

Nicolas · 1 year ago

You'll be happy to know that with haXe 2.0 release :

- you can now remap packages with --remap flash:noflash (to fix your first problem)

- array bug has been fixed in neko 1.7.1

- there is crossplatform haxe.Int32 support (and crossplatform haxe.io + haxe.io.Bytes as well)

James Urquhart · 1 year ago

Thanks again Nicolas! :)

Great to see all of those quirks fixed. My only criticism would be that Int32 is still not treated as a normal integer type, so code ends up filled with quirky looking "Int32.dothis(Int32.dothat())" statements. Would have thought if you could abstract the whole language onto another, you'd be able to abstract the Int32 as to act as an Int as well.

Regardless, i actually managed to compile hiscumm in haXe 2.0 with very minor modifications. Only problem is, to use the new haxe.Int32 stuff i have to re-do the whole IO code again. Eeek!

Still, i'm very pleased with haXe 2.0, and look forward to future uses of it in production environments. :)