Pagine    Articoli    Prodotti    Forum    Cerca  
Nickname

Password


Non sei registrato?
Registrati a GPI qui!

Puoi anche attivare un vecchio utente GPI e chiedere una nuova password.
I Team

Mappa Team
I nostri utenti

Mappa Utenti
  Develop HTML5 games without javascript for flash developers – Part 2: Jangaroo
Pubblicato da Sebastiano Mandalá il 2012-08-05 22:21:35

The reason why I called the first tutorial of this series Part 1 is because I knew there were other alternatives around to develop HTML5 games, carefully avoiding javascript.

 

However after some researches I found out that the only really working alternative suitable for actionscript developers is Jangaroo.

 

Let’s talk a little bit about it. Jangaroo is an open-source project mainly used by the German company Coremedia. The smart guys from Coremedia hate javascript so much that they decided to create a compiler capable to convert actionscript 3 to javascript and they called it Jangaroo.

 

However Jangaroo has not been created with the intent to support Flash libraries (including the display list), what the developers had in mind was just to have a way to create web applications with a language different from Javascript.

Jangaroo is for actionscript 3 what HaxeJS is for Haxe, that is a way to entirely map a language into another. In fact Jangaroo is mainly used with pre-existent and remapped javascript libraries, that is more or less what happens with HaxeJS.

 

This part of Jangaroo is supposed to be quite stable, in fact it has been already used for several internal projects at Coremedia. It is also interesting to note that several open-source applications have been made with it. Among these projects we can find the porting of the 2D engine Flixel and the physic engine Box2D.

 

The main source code of Jangaroo and all the applications can be found on several github repositories.

 

The first impact I had when I read the clear (but a little bit outdated) tutorial was: woah woah woah, what? Do I have to install Maven to run it?! Seriously?! It must be a pain!

 

Thus, since for a long while now I wanted to try Realaxy IDE (man, it is not really easy to remember how to spell it) and since I knew that the beta version 1.1 is supporting jangaroo to convert the actionscript code to JS, I decided to install it thinking it would have been a smart decision.

Instead few minutes using it were enough to understand that it was a big mistake! First it is java based = a pachydermic piece of software as slow as the other incredibly overrated IDE Eclipse (and its cousin Flash Builder), second it lightly decided to delete my project folder, including all the code I have manually converted from the previous Haxe version of my experiment, that of course I did not back up urggghhh.

 

By the way, this is something that could be interesting: I actually tried to convert the Haxe code to actionscript 3 using the automatic method that Haxe provides, but it failed in several ways and so I had to spend more or less an hour to manually convert the source code.

 

At this point I decided to go for Maven and surprisingly everything worked out smoothly and painlessly. What Jangaroo asks to install in order to work is just the last version of Java Runtime Environment and Maven, nothing else.

 

The only thing to pay attention to (as explained in the tutorial) is to set the JAVA_HOME environment variable that must point to the folder where the JRE is installed.

 

Now everything is set to follow the aforementioned Jangaroo tutorial, which explains in few steps how to create the first “hello world” application without using flash libraries.

 

With the knowledge gathered so far, you will be able to create a javascript based application using actionscript 3, but you will not be able to use the display list to make games.

 

Although the goal of this tutorial is to show to the reader how to use the Display List in jangaroo to make HTML5 games, let’s be clear: I am not a fan of the Display List and I do not think it is a good data structure to use for HTML5 games. So even if Jangaroo, as we will find out, has some flaws in converting the display list related code, I would not say this is a great limitation.

The real problem is that from now on the documentation become very scarce. Your main source of information will be GitHub and the Jangaroo group on google. They are both managed by Frank Wienberg, who is the most active Coremedia employee developing and maintaining the project.

 

Honestly, while Frank is a great guy willing to help as much as he can, the fact that he is alone is another relatively big limitation of the project. In my opinion Jangaroo needs a bigger community to become really successful and I think it even deserves it. More people should at least give it a try, that’s also why I am happy to write this article.

 

In order to work with the DisplayList, the next step is to extend the pom.xml file. The pom.xml is a config file needed by Maven to understand what to do and which libraries to use.

 

I do not think it is necessary at this point to explain every single node inside the XML, since the jangaroo tutorial is quite simple to understand. However in order to get more information two options are available:

One is to use the template example in github, the other one is to use FlashDevelop and download the template to create a working jangaroo project.

 

Once the template is installed and the project is created, the pom.xml will be generated automatically inside the project folder; just be careful that Flashdevelop uses the JAVA_HOME variable as well, but it is NOT compatible with the 64bit version of JRE. In case you have both the 32bit and the 64bit versions installed and you decided to use the 64bit version to run maven, I suggest to edit the FD jvm.config file to instruct it to use JRE 32bit.

 

Do not be afraid to open the xml file, it is quite self explanatory. The only attributes you need really to take care of are    and . The value inside must be kept updated with the latest version of the libraries available. Maven will automatically download it the first time the project will be compiled. Totally awesome!

I guess that the Maven repository is a good place where to check the latest Jangaroo version (the preview versions seems to not support the flash libraries yet).

 

Other two important nodes of the Pom.xml file are the  node and the node.

 

The dependencies node tells Maven which other libraries to use while compiling the source code.

For this article sake, it is important to know that jooflash, which is the library that enables the flash library, is not part of the standard jangaroo library, but it is among the extra ones and so it must be included inside the dependencies node.

   

<!-- To use Jangaroo Flash library, all you need is this dependency: --> net.jangaroo jooflash ${jangaroo_libs_version} jangaroo

  

Jooflash is a side project developed exclusively by Frank Wienberg, therefore it is not as stable or as complete as the main Jangaroo library.

 

the resources node is instead useful if you want to embed resources using the meta tag [Embed(source = "...")] 

 

src/main/assets **/*.png **/*.jpg joo/assets webapp

 

Ok, I think I have said everything is needed to say to let you work with Jangaroo. Now let’s talk about my results.

My intent was to compare the performance of Jangaroo against the Jeash performance using the incredibly bad code I wrote for the shoot’em’up I have created for the first tutorial of this series.

However in this case bad code adds value to the experiment, because it can be used to gauge how good the compiler is.

 

The results are quite interesting.

 

At first it seems that Jeash beats Jangaroo in every aspect. Jeash is infact much faster (60fps against 30fps) and much more compatible across the browsers (the game works on every modern browser known using Jeash, while the Jangaroo version behaves quite differently and in some cases wrongly). Jeash seems to use pretty neat CSS tricks to incredibly optimize the performance.

 

However there is a very important aspect to take in consideration: Canvas blitting. In this case Jangaroo seems way better than Jeash.

 

Both version of FlashPunk and Flixel, as the flash coders know already, use only bitmap blitting to render the entire screen without using the flash display list at all. It is pure old school 2D blitting.

 

@teormech on Twitter is currently porting Flixel to Haxe and experimenting with Jeash as well. He found out that the Jangaroo Flx invasion demo runs 3 times faster than his Jeash porting. According my profiling the Jangaroo version of the game takes approximately 3ms to render the 640x480 screen, while the Jeash version takes about 12ms!!!

 

That means that for pure canvas application currently Jeash performance is very disappointing.      

 

This is all and this is very likely my last article regarding HTML5 technology. I have always been skeptical about HTML5 as platform for videogame developers and the current performance on desktop, but especially on mobile, demonstrate that HTML5 is not ready for professional game development.

 

Note: My first article and the considerations about Jeash written in this one are based on the latest version of Jeash (0.8.7) before it has been merged to HaxeNME. Unfortunately as today, the jeash version included in HaxeNME appears to be totally broken. Jeash seems to be sensibly worse than the previous version I worked with.

 

Questo articolo è stato riportato dal mio blog tecnico che potete trovare su blog.sebaslab.com

Campagne crowfunding

Just One Line
Siamo presenti su

     
Copyright ©2016 - Manifesto - Privacy - Termini di Servizio - Community - Collaboratori - Contattaci