Vérifie que ton pare feu n’empeche pas GD de fonctionner ( autorise toutes les communications entrantes et sortantes ). Affiche la console de développement web ( Firefox > Outils > Développeur web > Console ou Chrome : Menu > Outils > Outils de développement ) pour voir si il y a un message d’erreur d’affiché. Essaie sur un modèle de jeu déjà existant si ce n’est pas déjà fait.
Quel est ton navigateur sinon ? Peut tu m’envoyer le jeu ?
J’ai trouvé le problème, Javascript prend les deux nombre pour des caractères, donc quand on fait par exemple 2 + 4, on obtient 24 et non pas 6.
Il faut donc utiliser parseFloat(nombre) pour tous les nombres dans une expression numérique (cool les langages faiblement typés).
En fait 2 + 4 donne bien 6 si 2 et 4 sont bien des “Number”, sauf qu’actuellement au chargement des variables initiales, les nombres flottants sont considérés comme des “String”, d’où le souci. J’ai corrigé ça, ça devrait être bon.
J’ai remplacé la taille des polices par une en pixel, il me semble que ça ne change pas grand chose hélas, mais bon…
Oui bizarre, ça vient de me faire la même chose ! Sans doute qu’il faut s’assurer de rafraichir la page entièrement pour que les fichiers js soient rechargés
Quand on ferme la fenêtre d’exportation en cliquant sur la croix, l’exportation a lieu alors que c’est censé ne pas exporter le jeu. Sinon, la minification ne marche pas.
Corrigé merci
Pour la minification en fait pour le moment, GD cherche l’executable java.exe dans 2/3 chemins par défaut : Je n’ai pas trouvé de méthodes pour obtenir le chemin où est installé Java Je vais rajouter une option pour indiquer manuellement l’emplacement de java.exe sinon.
Je rédige des pages de documentation pour le SDK et je mettrai une version officielle en ligne si il n’y a plus de gros soucis. ( J’ai encore corrigé divers problèmes, tous les exemples marchent à nouveau ). Il restera à adapter assez vite le tuto pour débutant dispo sur le wiki ( j’ai redigé son équivalent anglais ces derniers jours )
Je vais surement placer les extensions officielles dans un dépot GitHub, ainsi que GDJS dans un autre dépot. ( Je me tate encore sur la license à appliquer à GDJS ).
Victor, tu peux me donner l’emplacement de java.exe chez toi ?
Tu as une drôle de façon d’hériter une “classe” (même si ça existe pas en Javascript, on se comprend) dans le code de GDJS.
Par exemple, pour TextRuntimeObject, tu crées une variable that qui contient l’objet “père” (RuntimeObject). Pourquoi ne pas faire un vrai héritage (par prototype ou pas) ? http://sebastien-dupire.info/faire-de-la-poo-avec-javascript.html (la fin du billet est importante)
En fait c’est un vrai héritage, enfin c’est ce qui est conseillé dans le livre “Javascript : The Good Parts”.
L’auteur préconise déjà d’éviter l’opérateur new : Pour cela, les constructeurs des objets créé eux mêmes les objets ( qui sont donc appelés that ) et les renvoient. ( L’autre manière de faire consiste à modifier l’objet this, puis l’opérateur new se charge de créé un nouvel objet et d’appliquer tout ce qu’on à fait à this au nouvel objet. Le soucis c’est que si on oublie l’opérateur new lors de l’appel au constructeur, on n’aura pas d’erreur : Javascript va appliquer la création de l’objet à un objet global sans signaler de problème ).
Ensuite, il décrit un moyen d’avoir de l’encapsulation : Définir une autre variable en plus de that, mais qui ne sera pas renvoyée. On l’appelle my et elle contient donc toute la partie privée d’un objet ( fonctions privées et propriétés privées ). Ca marche car Javascript retient le contexte lors de l’appel des fonctions : Tant que l’objet existe, les fonctions de l’objet existe, et comme elles font parfois référence à my, my existe.
Enfin pour l’héritage, il suffit, lors de la construction de l’objet, d’appeler sur that le constructeur de l’objet père. Lors d’un héritage “habituel” on fait la même chose, mais directement sur this. Ici, je le fais sur that, mais c’est la même chose : that est bien l’objet qu’on construit.
( Le seul truc qui est pas pratique, c’est que un objet fils ne peut pas accéder à la partie privée de son père ( Tant mieux d’une certaine façon, c’est le principe d’une partie privée ). Mais il y a le même soucis avec l’héritage classique ! )
EDIT : Ce que j’utilise s’appelle le “Functional inheritance”, voilà un petit comparatif : richard-foy.fr/blog/2011/10/ … heritance/
EDIT2 : C’est vrai qu’il y a peut être une pénalité en performance… Quand j’aurai le temps, je testerai de convertir les classes au modèle “habituel” “prototypal” et je verrai si ça augmente de façon sensible les performances sur quelques benchmark.
Les articles que j’ai lus n’évoquait pas cette méthode d’héritage. En effet, elle est plus simple que l’héritage par prototype.
EDIT en réponse à EDIT2 : Faut éviter de toujours essayer d’optimiser quand les performances sont correctes.
Oui c’est moins connu mais je trouve ça plus simple et plutôt élégant. Mais c’est vrai que je n’étais pas au courant qu’il y avait un risque de performance un peu moindre ( surtout à la création des objets si j’ai bien compris ) comme je le disais dans mes EDIT au dessus. Faudra que je fasse des tests, au pire repasser au modèle classique sera à tester ( et à conserver si c’est concluant niveau performance, même si c’est dommage de perdre le coté encapsulation ).
EDIT en réponse à ton EDIT ( ) : Oui mais c’est vrai que lorsque j’ai fait un test avec la création de 1000 objets, ça ramouillait quand même au lancement, et puis c’est toujours appréciable d’avoir un gain de performance sans trop défigurer au final la bibliothèque. A voir !
Je me pose la question également au niveau de la consommation mémoire : quand on utilise pas le prototype, les méthodes sont re-déclarées pour chaque objet comme l’est un attribut (elle va donc occuper un espace mémoire). Alors qu’avec le prototype, la méthode est globale à l’objet (déclarée qu’une fois) et est seulement utilisée avec un contexte d’exécution différent selon l’instance depuis laquelle elle est appelée. Par contre, avec le prototype, l’appel de la méthode est légèrement moins rapide.
EDIT : Pourquoi pas une licence LGPL pour GDJS ? (je pense pas que GPL soit possible vu que tu l’utilises avec GD qui n’est pas libre).
EDIT2 : Nouveau bug :
[10:01:49,292] TypeError: gdjs.mainCode.GDJoueur1Objects4[0].getAverageForce(...) is null @ http://localhost:2828/code0.js:327
Les expressions Force moyenne en X et Force moyenne en Y ne marchent pas.
Oui ça doit consommer plus question mémoire à cause des méthodes spécifiques à chaque objet ( et ça va de pair avec une initialisation plus longue donc ). Je testerai le passage à un héritage “classique” dès que je pourrai.
Ouais, je vais opter pour la LPGL.
C’est corrigé pour le bug, ça ne marchait pas quand l’objet était à l’arrêt
Sans doute qu’il faut s’assurer de rafraichir la page entièrement pour que les fichiers js soient rechargés 
Je vais rajouter une option pour indiquer manuellement l’emplacement de java.exe sinon.
) : Oui mais c’est vrai que lorsque j’ai fait un test avec la création de 1000 objets, ça ramouillait quand même au lancement, et puis c’est toujours appréciable d’avoir un gain de performance sans trop défigurer au final la bibliothèque. A voir !