|
FibonacciSpaghetti
|
 |
« on: July 03, 2012, 06:05:21 PM » |
|
I've done a lot of programming in AS3 up to this point, and ran across Haxe recently. It seems too good to be true... an AS3-like language that can compile to just about anything. Is there something I'm overlooking, or should I be coding all my stuff in this language?
|
|
|
|
|
Logged
|
|
|
|
|
Vince_Lawrence
Guest
|
 |
« Reply #1 on: July 03, 2012, 07:34:47 PM » |
|
To get a feel for the shift between those two which is AS3 and haXe[/b]. Being based on the same specification as Actionscript, the transition was woefully painless and required barely any documentation references. If anything it was tedious because things were THAT similar, but to that end there are tools for converting AS3 classes to HX classes that do a surprisingly good job in as3tohaxe. Within no time all the hard work that went into my math and display libraries was available for use within haXe, and I was publishing out to a swf (with an amazingly fast compile time). The canvas and its context objects are not available in haXe. However, they have added a some tools to help overcome this obstacle with a little additional typing, but no rocket science. Due to the fact that Javascript isn’t a compiled language, the definitions aren’t actually available until runtime. To this end haXe has a keyword ‘extern’ which indicates to the compiler that the actual class will be defined at when the application has run, such as the case with custom Javascript classes or libraries or ones that just aren’t included in the haXe API. While haXe also allows you to just throw type safety out the window, having code hints when working with an uknown such as the canvas rendering context, it helped to do the little extra work to define the API, which was readily swapped out for the real thing come runtime and yeah, i must say you should!
|
|
|
|
|
Logged
|
|
|
|
|
larsiusprime
|
 |
« Reply #2 on: July 03, 2012, 08:56:06 PM » |
|
So you're saying that if you have an existing as3 code base it's a much better idea to port it to HaXe to get cross-platform and mobile support rather than spring for something like unity?
|
|
|
|
|
Logged
|
Nostrils!
|
|
|
|
Vince_Lawrence
Guest
|
 |
« Reply #3 on: July 03, 2012, 09:04:06 PM » |
|
Exactly 
|
|
|
|
|
Logged
|
|
|
|
|
Moczan
|
 |
« Reply #4 on: July 04, 2012, 01:30:40 AM » |
|
So you're saying that if you have an existing as3 code base it's a much better idea to port it to HaXe to get cross-platform and mobile support rather than spring for something like unity?
It will still be a lot of work, if you want your game to hit desktops and mobiles you not only have to rewrite your as3 to haxe (that's easy, there are just few differences like lack of for loop etc.), but write shitload of #if flash, #if iphone, because there is a lot of undocumented inconsistency and performance differences between platforms with NME. It's great if you want as3-similar language for native games for one platform, though. Considering that, for building desktop, web and mobile games from same codebase, Unity will save you a lot of time in the long run.
|
|
|
|
|
Logged
|
|
|
|
|
agersant
|
 |
« Reply #5 on: July 04, 2012, 01:46:43 AM » |
|
Been using it for ~5 years, it's a great language. Go for it =)
|
|
|
|
|
Logged
|
|
|
|
|
Sam
|
 |
« Reply #6 on: July 04, 2012, 03:02:13 AM » |
|
I've (so far) only used it to compile to Flash, but still find it valuable and just plain nicer to work with than AS3. As a language it has richer features than AS3, with generic typing and the option to inline functions especially valuable to me. It also has a shader language "HxSL" built in (similar to GLSL or HLSL) that can produce the shader bytecode needed for Stage3d work - which Adobe themselves never bothered to make a proper tool for. As Moczan says, be aware that although it's good for crossplatform work it's not magic. All my input and output code is littered with use of the Flash API: adding Sprites to DisplayObjects, listening for MouseEvents, handling the Stage3D context, and all that stuff. This of course means that I can't just press a button and compile to Javascript to make an HTML5 game. I probably should have littered it with calls to the NME API instead, which follows the style of the Flash API (although doesn't recreate nearly all of it) but will switch out what it compiles to depending on the target. That would make it pretty close to the "one code base for many platforms" ideal, but in practice you're always going to have sections of code that are swapped out depending on the target platform. Generally the less worried you are about performance, the less platform-specific code you'll need to write.
|
|
|
|
|
Logged
|
|
|
|
|
FibonacciSpaghetti
|
 |
« Reply #7 on: July 04, 2012, 03:07:06 AM » |
|
Thanks everyone. I think I will go for it as no one has posted any negatives here. Guess I should have known it still wouldn't be a "write-once-run-everywhere" kind of thing, but if I recall, even Objective-C can't claim that for the small number of devices it supports.
I'm glad to have something to jump to if Adobe gives up on Flash entirely. Plus, haxelib totally rocks. Wish I had something like that before... instead of having to go download TweenLite a million times.
|
|
|
|
|
Logged
|
|
|
|
|
tametick
|
 |
« Reply #8 on: July 04, 2012, 07:40:09 AM » |
|
Been using haxe for all of my games for over a year now (including commercial ones). It's great (for several reasons), but as said before it's not magic.
There are some rough spots (in particular with nme and the hxcpp target) but the pros outnumber the cons greatly. Even for just flash games I much prefer using haxe & would never really use as3 these days without a really good reason.
|
|
|
|
|
Logged
|
|
|
|
|
Evan Balster
|
 |
« Reply #9 on: July 04, 2012, 09:38:20 AM » |
|
I'm a little bothered by the lack of antialiasing support (and graphics options in general) in NME, though I haven't dived into its API firsthand. I'm presently helping someone out on a Haxe/NME project and to be frank I doubt I'd take it over C++ in the portability department.
[/hater]
|
|
|
|
|
Logged
|
|
|
|
|
larsiusprime
|
 |
« Reply #10 on: July 04, 2012, 10:56:01 AM » |
|
Sounds super cool! My latest game runs off of flixel (pretty old version), so most of the calls to the flash display/drawing API stuff is abstracted out into there. Does NME play nicely with flixel-esque CPU-based sprite blitting?
Definitely will give this a try for my next game.
|
|
|
|
« Last Edit: July 04, 2012, 11:14:15 AM by larsiusprime »
|
Logged
|
Nostrils!
|
|
|
|
Moczan
|
 |
« Reply #11 on: July 04, 2012, 11:23:39 AM » |
|
Sounds super cool! My latest game runs off of flixel (pretty old version), so most of the calls to the flash display/drawing API stuff is abstracted out into there. Does NME play nicely with flixel-esque CPU-based sprite blitting?
Definitely will give this a try for my next game.
Yep, the Bitmap and BitmapData are still there with almost same functionality, but it also has a really powerful, GPU based drawTiles function (for cpp targets only), if you take a day or two to learn it and abstract your classes around it, you get unlimited sprite blitting + almost free rotation and alpha blending on desktops and mobiles.
|
|
|
|
|
Logged
|
|
|
|
|
tametick
|
 |
« Reply #12 on: July 04, 2012, 12:21:29 PM » |
|
|
|
|
|
|
Logged
|
|
|
|
|
FibonacciSpaghetti
|
 |
« Reply #13 on: July 04, 2012, 01:41:16 PM » |
|
I was playing around with HaxePunk... same deal with FlashPunk/Flixel? Just different ways of doing the same thing.
Granted... I kinda like the way flixel goes about things more, so this is a cool find.
|
|
|
|
|
Logged
|
|
|
|
|