Haxe NME goes social.
You can by now use Facebook in your Haxe NME project ( for iOS & Android targets only ).
Grab it at : https://github.com/shoebox/HypFacebook
The twitter extension ( for iOS / Android / CPP ) will be soon available too.
20
Jan 13
NativeMirror : Easier way to make JNI/CPP calls from haxe
It’s still useful to know how to make native calls from haxe manually ( for debugging by example ) but there is a quicker and easier way.
It’s stricly type, flexible and simple.
It use a simple macro you can find here : here.
All you have to do is to add it on build of yours haxe class.
1 2 3 | package org.shoebox.test; @:build(org.shoebox.utils.JNIMirror.build( )) class Test{ } |
Then all you need to do is to create mirrors for the native methods.
Mirrors for JNI Methods
Basic example:
In the following case the JNI class name and method name are not defined.
So the macro use the same classpath classname and function name than on the haxe side.
If the haxe method name or package is not the same on the java side:
You can customize both by adding argments to the JNI meta:
1 2 |
For non native types:
It works too for non-native type if the class exists on both side ( with the same package and class name ).
By example we are trying to get the instance of the java class Test inside haxe, the method is defined this way:
1 2 3 | @JNI static public function getInstance( ):Test{ } |
For CPP Methods
It works the same way, but the first meta argument ( library_name ) must be always defined ( for now ).
The second meta argument ( method_name ) is optional.
1 2 |
Hope it helps.
18
Jan 13
NME Native Extension Part 2 : Calling CPP methods from haxe
Much more easier than JNI methods, all you have to do is using the “cpp.Lib” class ( “neko.Lib” for neko ).
1 | Lib.load( libName , primitiveName , argsCount ); |
LibName:
It’s the cpp library name ( without path and extension ).
PrimitiveName:
The name of the primitive defined in the ExternalInterface class.
In the next article of the tutorial we will take a look at how to define the primitive in the ExternalInterface class, which is the backbone of the native extension.
ArgsCount:
Obviously it’s the argument count used by the primitive.
This will return like for JNI, a function which can be call with the correct number of arguments.
06
Jan 13
NME Native Extension Part 1 – Android : Calling Java methods from Haxe
The JNI class (nme.JNI) allow native haxe code to call Java methods.
For static method the function call is :
1 | nme.JNI.createStaticMethod( package_name , "method_name" , signature ) |
for non-static method it’s :
1 | nme.JNI.createMemberMethod( package_name , "method_name" , signature ) |
Package name:
The package is the full class package and class name separated by slash ( example: “org.shoebox.Test” is “org/shoebox/Test” )
The signature :
The signature of the method is a string:
( mapped arguments type ) return_type
First thing to know is than the arguments type must be mapped for Java.
For the basics types just follow the following table:
For the non basic types ( by example a class instance ) the mapping is:
Lpackage/of/the/ClassName;
Some examples:
On the java side :
1 2 3 4 5 | static public DemoJNI getInstance( ){} static public boolean test_ret_bool( ){} public boolean test_method_nonstatic( i : Int , b : boolean ){} |
On the haxe side for the statics methods :
1 2 3 4 | var f1 = nme.JNI.createStaticMethod( "org/shoebox/DemoJNI" , "getInstance" , "()Lorg/shoebox/DemoJNI;" ); var instance = f1( ); var f2 = nme.JNI.createStaticMethod "org/shoebox/DemoJNI" , "test_ret_boo" , "()Z" ); var b = f2( ); |
For member methods calls you must pass as argument the JNI class instance ( by example the result of the getInstance( ) method )
1 2 | var f3 = nme.JNI.createMemberMethod "org/shoebox/DemoJNI" , "test_method_nonstatic" , "(IZ)Z" ); f3( instance , 10 , false ); |
Quite easy isn’t it ? When you have understand the java mapping it’s quite easy to call any java method from Haxe.
11
Nov 12
Arkeon pour Android & iOs
Notre premier jeu entièrement fait avec NME est enfin disponible sur le Google Play Store, et après une (très) longue attente sur l’Appstore d’Apple. Une sortie pour l’amazon app-store, ainsi que pour le mac app-store est en route.
Vu qu’il y a pas mal de questions venant de la part de “curieux” concernant NME, je vais faire une série d’articles “post-mortem” sur le développement de jeux multiplateformes et multi-écrans avec NME.
Mais tout d’abord je vais donc faire un post téléchat pour chaudement vous recommander cet excellent jeu.
Un jeu inédit pour les passionnés de jeux d’échecs et jeux abstraits.
Votre but ? Détruire un adversaire pour prouver votre suprématie.
Vos armes? Des unités basiques et des unités avancées.
Dans Arkeon, tous les joueurs commencent la partie avec les mêmes armes, il n’y a pas de place pour le hasard. Soyez le meilleur stratège ou soyez détruit. Pour vaincre, une de vos unités offensives doit attaquer la base adverse. Mais attention aux offensives trop hâtives car si l’ennemi vous coupe de votre base vous perdrez toutes vos unités isolées. Faites évoluer vos unités basiques pour semer le trouble dans la stratégie adverse et vous sortir des mauvais pas. Puis faites les régresser pour récupérer vos unités avancées et les redéployer à un endroit plus stratégique. Si vous aimez les jeux d’échecs, de dames, et plus généralement les jeux abstraits, Arkeon innove et vous propose un mix inédit entre un jeu de connexion et jeu de stratégie. Maîtrisez vos pièces énergétiques et percez les secrets de la construction d’une stratégie gagnante.- Affrontez l’intelligence artificielle d’Arkeon dans le mode “un joueur”.
- Défiez vos amis dans le mode “deux joueurs”.
- Facile à comprendre mais difficile à maîtriser.
- Accessible à tous, à partir de 7 ans.
01
Jul 12
HyperTouch : Haxe NME Native Gestures
Les Gestures dans les applications Android & iOS, sont le nerf de la guerre. Cela donne une impression de fluidité et de facilitée d’utilisation lorsqu’il sont bien implémentés.
Mais le problème actuel est que Haxe NME n’a actuellement aucun support pour la détection de gestures. Il existe des librairies HaXe très bien conçues qui permettent d’émuler des gestures à base de TouchEvent ( comme Gestouch ). Mais le résultat est rarement aussi parfait et sensible que les réglages crées par Google et Apple dans leurs SDK.
Les gestures émulés étant souvent basés sur des Timers entre deux TouchEvent, le délai pour un tap ( par exemple ) était bien souvent trop rapide pour tel ou tel personne. Cela avait un coté frustant de donner à tester à un tier une application et se rendre compte que celui-ci n’arrivait pas à ouvrir en menu qu’en faisant au moins trois tap sur l’écran…
Je me suis donc alors penché sur les librairies natives d’HaXe NME pour créer HyperTouch.
HyperTouch permet d’utiliser facilement et rapidement des gestures sous Android & iOS. il suffit de lier la librairie et de poser les écouteurs.
HyperTouch utilise le gestionnaire de gesture natif à iOS & Android, il n’y a pas besoin de librairies tiers, et c’est compatible avec toutes les versions d’iOS et d’android (à ma connaissance).
Utilisation
Il suffit juste d’ajouter le chemin vers l’extension dans votre description de projet NME (NMML)
1 | <include path="extensions/hypertouch" if="mobile"/> |
Ensuite via la classe singleton HyperTouch ajouter des écouteurs pour chaque type de gestures souhaité.
1 |
1 2 3 4 5 | <em><span style="color: #000000;">var hyp = HyperTouch.getInstance( );</span></em> <em> <span style="color: #000000;"> hyp.addEventListener( GesturePanEvent.PAN , _onPan , false );</span></em> <em> <span style="color: #000000;"> hyp.addEventListener( GesturePinchEvent.PINCH , _onPinch , false );</span></em> <em> <span style="color: #000000;"> hyp.addEventListener( GestureSwipeEvent.SWIPE , _onSwipe , false );</span></em> <em> <span style="color: #000000;"> (...)</span></em><em></em> |
A savoir
L’extension n’active à un instant T que les gestures qui sont écoutés sur la classe HyperTouch. Donc pensez bien à supprimer vos écouteurs lorsque vous en avez fini 
( ce qui est de toute manière chaudement recommandé ).
Les coordonnées de position de geste ( par exemple un simple Tap ) sont liées à la scène et à l’orientation courante. Il vous faudra donc les convertir en coordonnées locales dans certains cas.
Actuellement les gestures reconnus sont:
- Simple Tap / Double Tap
- Two Fingers Tap (seulement sous iOS pour l’instant )
- Pinch
- Rotate (seulement sous iOS pour l’instant )
- Swipe
- Pan
Todo
Il reste beaucoup à faire.
Ce qu’il faut savoir tout d’abord est que je ne suis pas un pro-coder en Java et encore moins en Objectif C, donc toute suggestion sera plus que bienvenue.
A part les quelques gestes qui reste à mettre en place, j’aimerai ajouter le support de la pression sous Android, une possibilité de changer le nombre de zones de touch nécessaires pour tel ou tel geste ( comme le pan et le swipe ). Régler quelques problème de concurrence entre certains gestes ( swipe vs pan par exemple )…
HyperTouch sur mon GitHub : ici.
A vous de toucher !
15
Feb 12
Sublime Text 2
Suite à mon passage a Haxe, j’avais besoin d’un bon éditeur de code compatible, fonctionnel et aussi puissant que ce j’avais avec Eclipse. J’ai donc testé plusieurs possibilités.
Les possibilités :
Ayant une licence FDT j’ai tout d’abord testé celui-ci, mais le portage Haxe est trivial (pour ce qui est de la gestion des librairies par exemple), bordélique, et buggé. J’ai toujours beaucoup aimé FDT pour le dev flash, mais pour l’instant pour ce qui est de HaXe ils se sont planté je pense.
Ensuite j’ai testé FlashDevelop, mais j’ai également eu pas mal de problèmes et de lourdeurs, et après avoir tout essayé pour avoir une configuration optimale j’ai abandonnée je suis tombé sur mon sauveur : Sublime Text 2 et son plugin HaXe.
Sublime Text 2
Joli non ?
Tout d’abord ce qui frappe après avoir utilisé FDT et Eclipse pendant des années c’est sa rapiditée incroyable et le fait qu’il consomme franchement peut de ressources système ( comparé à Eclipse il y a un monde ). Même sur mon MacBook l’appli se lance instantanément, et on peut switch entre des projets tout aussi rapidement.
C’est compatible pour de très nombreux languages de prog, et le support de HaXe peut être ajouté facilement via un simple petit plugin disponible sur le github de clemos dont la nouvelle version supporte parfaitement la compilation NME, l’autocomplétion…
Soyons franc, c’est un logiciel fait par des devs pour des devs : tout est customisable / configurable via des fichiers JSON et vous pouvez facilement ajouter / créer tel ou tel plugin via le “Package Control” ( c’est du python ).
De nombreux “packages” ( plugins ) sont disponibles, mais il y a quelques essentiel comme Aligner qui permet d’aligner les variables / type… sur plusieurs lignes ( pour un maniac comme moi qui aime tout aligner pour rendre visible le code cela fait gagner pas mal de temps ), le plugin Git, le thème Soda…
Enfin bref si vous n’avez pas encore succombé au sublime comme de nombreux devs que je connais, je vous conseille chaudement de le tester, mais je vous préviens vous risquez rapidement de ne plus pouvoir revenir en arrière.
08
Jan 12
Et maintenant ?
Après les annonces (mal) faites par Adobe et que de nombreuses personnes ont interprété comme étant un abandon de la plateforme, de nombreux développeurs flash ( moi y compris ) se sont posé la question : “Il y a t-il un avenir dans la plateforme flash ? et surtout doit-je encore utiliser AIR pour mon développement multisupports ?“
Veuillez noter que cet avis est personnel, et plutôt typé dans un objectif d’application de type jeu, ou très gourmande en ressources graphiques.
La situation actuelle :
Notre métier a rapidement muté ces dernières année. Autrefois on nous demandait uniquement de développer des sites internet ou ponctuellement une application desktop, mais le mobile est arrivé et a bousculé pas mal de choses.
Le nombre de devices / OS différents ne facilite pas les choses, mais la force principale de AIR est que le même logiciel fonctionne sur ( quasi ) toutes plateformes et ( quasi ) tout les devices, et c’est sans aucun doute sa force.
Mais AIR à également de grosses faiblesses :
- Des performances trop faibles et inconstantes :
C’est pour moi le point noir principal, la machine virtuelle embarqué consomme bien trop de puissance / mémoire. J’ai connu des baisses de puissances inexplicables, des lags ( par exemple sur iPad si Safari est ouvert en tâche de fond ), voir des crashs.
Le fait que AIR requiert l’ARMV7 ne nous permet pas de l’utiliser pour des iDevices un peu plus “anciens” mais encore très utilisé ( iPhone 3G , iPod Touch 1-2G… ).
- Le process de test / compilation / debug sous iOS :
C’est long, compliqué et pénible, et impose d’utilise le logiciel le moins ergonomique du monde ( et peut – être le plus lent ) : iTunes.
C’est tout aussi, voir plus compliqué pour les Extensions Natives.
- Le poids de l’application finale:
Le poids de l’application finale explose rapidement à cause du poids de la machine virtuelle embarquée. Et je ne parle pas de l’ajout de poids qui arrive après que l’application a été soumise à Apple.
On se heurte vite à la limite des 20Mb de téléchargement en 3G.
Personnellement, dans l’objectif de créer des applications mobile stables et performantes sous plusieurs plateformes j’ai abandonné la plateforme flash Adobe… aprés les nombreux déboire que j’ai eu lors de mon dernier projet.
Les alternatives :
Donc comme j’ai décidé d’abandonner AIR, j’ai passé quelques temps a tester pas mal de technologies / solutions alternatives qui ont toutes des forces et bien souvent de faiblesses.
- HTML5 : Alias le bouclier d’Apple contre les impies développeurs flash.
Un jour peut-être ce sera viable, mais actuellement les performances sur les différents navigateurs de l’html5 et de javascript ( vu que pas mal de personne confondent HTML5 et javascript ) sont bien trop inégales.
Il y a également de nombreux problèmes bien plus profond. Il y a de nombreux retours d’expérience intéressant de différents développeurs sur le sujet sur internet.
- MonoTouch & Monodroid:
La solution sur le papier semblait très intéressante, le C# est d’après moi à la portée de tout développeur flash, mais vu qu’il est impossible de tester sur un device la solution sans passer à la caisse, Mono je vous avoue ne m’a pas séduit.
- Unreal Developement Kit (UDK ) :
Extrêmement puissant, orienté jeu, c’est la rolls royce des outils pour créer un jeu. Mais il est officiellement impossible de cibler Android ( officieusement c’est possible ) et l’export flash est toujours en cours de développement.
- Unity3D :
Lui aussi extrêmement puissant, mais je le trouve moins intuitif, et n’a pas l’éditeur graphique de code de l’UDK. Mais permet de cibler Android / Flash / iOS / XBox …
Je ne parlerai pas du natif, car l’objectif est de conserver l’aspect multi-plateforme, mais c’est une solution viable. Ensuite je n’évoque pas non plus MoleHill, car ce n’est toujours pas disponible sur mobile, mais d’après les retours d’expérience que j’ai eu via la prerelease je ne suis pas convaincu ( je n’en dirai pas plus pour cause de NDA )
Ma solution :
Aprés pas ma de recherches j’ai finalement trouvé ma solution idéale : Haxe NME !
Haxe NME ?
Haxe était un peu pour moi le coté obscur du dev flash. Pourquoi apprendre un langage décliné de l’as3 pour obtenir du flash que j’obtient déja en faisant de l’AS3 ? J’ai rapidement changé d’avis en constatant sa puissance et sa souplesse.
NME permet à partir du même code Haxe de générer du code NATIF et PERFORMANT pour iOs / Android / WebOS / Windows / MacOs / Linux et même HTML5, via du cross compiling. Le code natif généré est debuggable, utilisable dans XCode ( ce qui simplifie énormément le process pour iOS ), Visual Studio, Eclipse…
Je ne m’étendrai pas sur les perfs de NME car de nombreux benchmarks existent, mais sachez que c’est fluide et rapide. NME est gratuit, open-source et “facile” d’accès pour tout développeur flash.
Solution parfaite ?
NME est toujours en cours de développement et manque de quelques petites choses (souvent liés au materiel) telle que l’accès au microphone, webcam… il est parfois possible de pallier le problème en utilisant des extensions natives. J’ai parfois connu quelques bug / crash que j’ai toujours réussi à debug assez facilement, mais cela impose une connaissance des process de debuggage Android / iOs…
Conclusion :
Faites votre choix selon vos besoins : pour des applications simples non gourmande en performances AIR fera l’affaire, si vous faites du jeu 3D je me pencherai vers Unity ou l’UDK. Pour du jeu 2D ( ou 3D vu que molehill existe également sous Haxe , ou toute type d’applications ) foncez sur Haxe & NME.
Après pour ce qui est de l’avenir de la “Flash Platform” je pense que grâce à la force de la communauté open-source elle va muter peu à peu pour se diriger vers des projets comme Haxe… , seule la partie 3D sera soutenue par Adobe ( ce qui semble être leur stratégie de toute façon ).
Pour l’avenir du développeur Flash, je pense que c’est maintenant qu’il faut prendre le train, ou bien rester à la traine. Bien sur cela demande de l’adaptation et un peu de formation, mais personnellement j’aime le challenge et le fait de continuer d’évoluer vers de nouveaux supports / devices / langages est pour moi le cœur de notre métier. Nous ne sommes plus des développeurs actionscript, mais des développeurs multi-supports.