I'm thinking about using Haxe in place of AS3.
What are the disadventages of that? I can think about:
Difficulties with using native AS3 libraries.
Difficulity of debugging after language translation.
Haxe is quite young, it may have some rough edges. Does it?
Does any one of you have expirience with Haxe dark sides?
What are the adventages? I've heard:
Performance.
Multiple targets (But I don't see how that is useful)
Better typing that AS3
Maybe better syntax.
Haxe is big enough that there should be more. What are the pros of Haxe?
Edit:
If there are no real disadvantages then why Haxe is not replacing AS3?
Your first point is surely true. Some "native" libraries (such as Flex) may require a little of gym to be included in your project. In the vast majority of cases it is a quite smooth process. Haxe supports multiple -swf-lib which permit to have the code of the imported assets immediately available in your application. Note that the imported libs are not just embedded but are recognized as code asset, so if your IDE is integrated with Haxe you will have type completion for that too.
About the debugging there are no issues at all for the translation, that because the language is not translated to AS3 but directly compiled to AVM2 bytecode. When the -debug switch is on, the full stack trace with source code references (filename, line and position) is fully preserved. An uncaught exception will point you exactly at the line of code that generated it.
Haxe is not really that young and for sure the AVM2 output is the one with the best support of all. There are no rough edges in my opinion.
Of the pros you have outlined I want to underline that multiple targets can be huge. Of course to take really advantage of it you can't really rely on external libs specific for AS3. Even so there are always big chunks of code that you want/can reuse across projects.
To mention a few other advantages:
macros are a recent addition which add a huge pool of possibilities.
Molehill API is already available for Haxe (SVN version) and Nicolas is working on a Shader system that makes it even bigger.
Haxe is evolving constantly bringing new (important) features at each release.
Related
If I wanted to create a "good old" desktop GUI program with some basic selectable vector graphics (arrows, colored boxes, text) to show mostly text and some diagrams (no need for 3D or particles, etc.) that then can be edited by the user, which Scala library would I use, and why? I'd want to build a tool for something similar to drawing diagrams.
Mostly I don't want to use things like D3.js or other web SVG stuff because it is painfully slow and can't show the amounts of content I want it to. But if there are exceptional advantages by using, say, Scala.js, for this purpose, it could be still of interest if there are no better means.
Alternatively, someone can point me to where this had been discussed? Did not find anything on Google or here.
Scala-Swing is a wrapper for Java Swing which is quite nice. As you may know, below Swing lies Java2D, so you will most likely want to look for Java2D based libraries. There aren't that many for Scala that I'm aware of, but more for Java (which you can easily use).
JFreeChart and scala-chart - more for charting
JGraph
JUNG
Processing might have some libraries for your use case
JHotDraw - not sure it's still maintained
NetBeans - not sure it's still maintained
Prefuse
And of course, if it's simple enough, there is nothing wrong with using Java2D directly.
Cocos2d-x 3.0 alpha was released for some time now. What was improved over cocos2dx-2?
The features list is quite important, but in terms of performance are there new limitations/improvements?
Have you noticed real improvements in performance, development patterns, APIs and support?
I've been using it recently and from what I've noticed the main differences are that everything is namespaced now, so you don't have to deal with the prefixed names that came from the objective c patterns, so cocos2d::Point instead of CCPoint (especially for enums, (Texture2D::PixelFormat::RGBA8888 instead of kCCTexture2DPixelFormat_RGBA8888)).
Also some of the event stuff now has support for c++11 lambdas.
A more complete list of the changes can be found here: http://www.cocos2d-x.org/wiki/Release_Notes_for_Cocos2d-x_v300
but for the most part of using it myself, it's just made to feel more like C++, instead of like objective-c.
I have switched and am finding it pretty stable. The main advantages so far ...
Real buttons, instead of menus
Real-time spritesheets
SpriteBatchNodes are no longer recommended and I did see a drop in draw calls where I not optimized
less objective C patterns.
more modern. namespaced instead of 'CC'. C++11.
more platforms supported
Main disadvantages for me:
EventListener pattern. I can't figure out how to get touch input to affect any objects other than the Node that triggered the event.
We use a lot of text-only buttons for debugging and they are hard to lay out :)
Lack of documentation and example code. For example, I could not find any documentation of how to use the Layout class anywhere.
It is a lot of work porting, but for us we had to decided to risk it since we would end up maintaining an out-of-date code base. It took about 5 person-days to port our game over. The game is now stable and we did not run into a single bug in cocos.
I think its C++11
auto
lambda
And it has no unnecessary use of prefix CC
One of the changes that happened between Cocos2d-x 2.1.5 and 2.2 was the removal of templates for projects in XCode (I do not know if project templates existed in VS, etc).
The new build system creates projects under the Cocos2d-x installation (at least on Mac) and that is where the project files appear to reference them. This makes it very difficult to move the project without hand tweaking. It also makes configuration management more painful, depending on how you set up your system (e.g. a root/tree like svn or a "drop it anywhere" like git).
Also, the Cocos2d-x library is built as that, a library. In previous incarnations, it was placed directly into the project. On one hand, if you don't alter the root library code, this makes good sense. On the other hand, if you occasionally tweak things for a specific project, you have altered all your projects that depend on it. Yin/Yang.
I'm still very positive on Cocos2d-x. I have not upgraded to 3.0 or 2.2 yet. When it matures a little more, I will switch over, regardless the changes. For what I need, I'm pretty sure it will still get the job done (well).
I've read a lot of books and watched videos on AS3 and they all teach very interesting techniques that I can harness and use. However, I'm in slight confusion because I've seen different techniques that contradict each other from different sources. For example, I've seen some developers write all their code within the timeline and handle it that way. Other times, I've seen developers handle their code in an .as file in Flex/Flash Builder/FlashDevelop. I know that there is no "right or wrong" way to do it, but what is the more preferred way by professionals?
As of now, I just use my .FLA to hold my assets and I write all my code in .AS.
Major projects shoulds strive to avoid timeline code at all times, since it will quickly become very hard to maintain, understand and version control. In these projects FLA's are mostly used to hold library assets, which are then linked into the project via swc-files.
It's fine to use FLA timeline code for small stuff like banners though.
Absolutely try to avoid timeline code if you can. It can really become a nightmare to read or expand. Using classes is a great way to start branching out of flash as well. As you get comfortable with referencing external files it is important to start using design patterns such as MVC (Model View Controller. It makes maintenance, debugging, expansion and handing off projects easier.
Proper way is to use Object oriented programming (OOP) with design patterns (DP).
EDIT:
From Wikipedia:
Design pattern is a general reusable solution to a commonly occurring problem within a given context in software design.
In my opinion design patterns are integral part of OOP (without DP you loose most of the advantages of Object oriented language).
You can learn design patterns for AS3 from this great book: ActionScript 3.0 Design Patterns: Object Oriented Programming Techniques. This book has an active blog with lots of interesting articles.
I program ActionScript for the FlashPlayer. This means compiling a set of ActionScript files into a SWF file (a bunch of bytecode that gets executed by the FlashPlayer in your browser). Anything that is not compiled into the SWF file must be requested. Examples of this would include ANY textual content, media, or graphical content that wasn't originally compiled in. Unfortunately this means dealing with a lot of asynchrony. A double-edged sword since dealing with asynchrony can be a pain in the ass, but can also be a fun force? on your design.
I just want to make the point that ActionScript is single-threaded, but the FlashPlayer is multi-threaded, so things like requesting content over HTTP are done in the background and we are notified of completion via an event broadcasting system (which is built into the language). So the issue here is not a concurrency issue (although I'm interested in any concurrency literature that might be relevant).
When I'm putting together a website I will be adding in functionality a little bit at a time. A little bit at a time usually translates into small steps. And by small step I mean small enough that I don't go from needing content to loading content (e.g. XML using HTTP) in one step. So I'll use, say... Fake It, but at some point I need to implement it for real, hence my search for literature on Refactoring To Asynchrony.
Any thoughts or help would be greatly apprecated. Thanks =)
There is astonishingly beautiful Reactive eXtensions for C# (all .net) and JavaScript.
It has been ported in ActionScript 3 as well and has its own wiki.
From description:
raix (Reactive And Interactive eXtensions) is a functional, composable, API for AS3 that simplifies working with data, regardless of whether its interactive (arrays) or reactive (events). raix was previously RxAs
Reactive part of it helps you to build highly asynchronous applications in simple intuitive way.
Hope it will help!
If one wanted to program a game in an unusual language, but no library or functions exist to manipulate graphics, how would this be accomplished? By writing your own low level routines?
You are standing by a house. A road runs off to the east, and south there is a narrow path leading around the back of the house.
There is a mailbox here.
What do you do? _
By interfacing to OpenGL, it's graphics-card independent API.
For a concrete example of what that means and how it's done, have a look at the OpenGL bindings for Python
Look here for bindings to other languages.
Why do you have to do this?
Well, graphics programming is highly dependent on the hardware (i.e. graphics card), and there are many of them. OpenGL is the standard language that they all understand. (I think the same can be said about Direct3D, but that's owned by Microsoft, while OpenGL is more open).
Find out how it interfaces with C libraries, then use that to make an interface to OpenGL, DirectX, or OpenAL. Alternatively you can port something else, like say SDLlib. In a weird case you might want to embed a language that has the library you'd like. Say if it's Java3D and you want to compile it with Mono 2.2. I'm not sure that's even possible, but one of the mono-project changes is Java support. Of course on Mono you have other game library options.
If you plan to use graphics hardware, you need to have its drivers and OpenGL or DirectX.
If you're programming this for some exotic piece of limited hardware, there's only so much you could do. If you're simply not given access to draw to the screen other than in some extremely limited manner (perhaps all you can do is render a string of text), then there's nothing you can do.
If you're doing this on an ordinary computer but your language of choice simply doesn't have any OpenGL or DirectX bindings, then you'll need to write some yourself.
Conventional wisdom would suggest to "use the best tool for the job", if there are no existing libraries to manipulate graphics for your language, it's likely not the best tool for the job.