Vraiment pas mal cette nouvelle version qui corrige pas mal de défauts !
J’aime bien l’aperçu qui s’enclenche immédiatement (et c’est bien plus logique).
Cependant, je regrette l’absence de l’objet Vidéo. Bien qu’il n’est pas très stable, je pense qu’il y a un moyen de l’améliorer (bon je m’y connais pas en programmation, mais il doit y avoir une possibilité quand même).
J’avais réussi à le faire fonctionner en mettant la vidéo avec le son, en glissant-déposant sur la scène et mettre aucun évènement, mais le jeu plante 1 fois sur 10 lorsqu’il est enclenché.
J’ai essayé de mettre l’objet Vidéo de Game Develop 2 sur Game Develop 3 avec son .xgdwe (que j’appelle “X Game Develop Week-End” ^^), mais il n’est pas pris en charge.
Bon, je sais bien que ça ne passe pas par du C++ vuue que c’est du JS -_- le terme compiler dans ce sens veux plutôt dire transformer le code natif en JS, le J2E fais ça, TypeScript le fais, et c’est ce qu’on utilise aussi pour arriver a asm.js, si il y a un meilleur termes que compiler je prends ^^
(ça c’est pour que il y ai pas de mal entendu vue que vous deux pensez que je ne vois pas la différence au vue de votre réponse x) )
Ce que je voulais dire question compilation, c’est où est tout le moteur de jeu ? Gestion des objets, du mapping, des déplacement physique etc… Pixi n’étant qu’un moteur de rendu, le moteur de jeu est bien quelque part, le xml ne donne que le contenu.
Je ne vois justement pas le code de la plateforme JS dans les sources, donc il est compilé dans code.js avec Pixi ?
Ok pour asm.js, ça se comprend par contre je me permet d’apporter précision.
Ce n’est pas Evenements → C++ → JS qui se passe dans emscriptem.
Le JS “c’est” du emscriptem, en fait le cheminement exact est JS → emscriptem → natif
Le truc c’est que en JS tu n’as pas de typage, donc il recompile tout le temps, en passant par asm.js tu forces une certaines logique de typage. emscriptem lors de la compilation il compare à chaque fois ce qu’il avait avant, et si au bout de x fois il voit qu’il a le même typage, alors il ne recompile plus cette fonction. C’est ce que fais que le js est lent, car emscriptem recompile toujours tout (c’est pas entré dans les détails mais en gros c’est ça, j’en avait discuté avec un ingénieur de chez mozilla qui m’a expliqué le concept).
Après oui, c’est fait pour traduire du C++ en JS, mais GD est en C++ non ? 'fin je veux dire, si tu fais un proxy qui interprète le xml et qui le renvoi au moteur qui est compilé en asm… (du moins moi je pensais que tu avais fais quelque chose du genre).
Ok cool de savoir que les amélios arrivent, ça m’étonne pas de toi à ce niveau, toujours réactif ^^
Je veux bien, mais je te dis qu’en benchmark sur des jeux en full HD j’ai de meilleurs perf… si le problème vient pas de Pixi il vient d’ailleurs, mais pour le moment la plupart des jeux que j’ai vue tourner sous rendu “webGL-2D” ont de moins bonne performances.
Si ça rame avec un canvas tout petit et un jeu super simple j’ose même pas imaginer ce que ça va donner avec des jeux en fullHD
Fais un test en mettant un canvas en 1920*1080 et des texture en 2048, si ça lag pas alors wai Pixi c’est cool, sinon c’est bof (mais faut que je le test Pixi de mon côté, donc je pourrais mieux en parler après avoir testé)
Le moteur de jeu se trouve dans le dossier JsPlatform\Runtime par rapport au dossier racine de Game Develop.
Les navigateurs web ne sont pas encore assez performants. Mais le jeu marche très bien sur Firefox Beta (aussi, les ralentissement sont volontaires quand les balle arrivent sur le personnage, ça fait partie du gameplay).
Dans ce cas, c’est pas normal
webGL, c’est une API copiée collée depuis OpenGL, et tout le rendu se fait avec le GPU, ce qui est théoriquement incontestablement plus rapide qu’un rendu software en manipulant des pixels du canvas.
Mais PIXI.js est non seulement rapide, mais aussi bien écrite : Elle detecte si webGL n’est pas activé, et si c’est le cas, le rendu est basculé sur Canvas. Donc en désactivant webGL dans ton navigateur, tu forcera PIXI.js à utiliser canvas. Maintenant, je suis pas sur que ça soit beaucoup plus rapide.
Après, il faut comparer ce qui est comparable. Pour de vrai mesures de performances, il faudrait tester exactement la même chose des deux cotés ( Genre rendu de 500 sprites qui bougent et qui tournent ) pour pouvoir vraiment se prononcer.
Les lags dans Soldier, c’est le moteur de jeu, pas le rendu
Le mieux est que tu teste Pixi.js par toi même : C’est un truc de bonne qualité, GD est parmi les premiers projets à l’utiliser, mais le gars qui code ça ( Mat groves : matgroves.com/ ) semble être plutôt doué, en tout cas beaucoup plus calé que moi dans le domaine
Pour emscripten, je me demande si il n’y a quand même pas une petite confusion : emscripten est un “compilateur” ( traducteur ) qui prend du code C++, le transforme en une représentation intermédiaire ( IR LLVM précisement ), puis cette représentation intermédiaire est enfin traduite en Javascript. Au bout du compte, on a donc du JS.
Les navigateurs récent se chargent eux de faire, au besoin, une compilation du JS qu’il lisent en code machine si jamais ils pensent que ça va accélérer la chose ( C’est de la compilation “juste-à-temps”, JIT en anglais ).
Enfin, asm.js est du javascript formaté de façon spécifique pour que les navigateurs interprètent ça très vite et optimisent ça en code machine qui tournera très vite aussi.
( Je reprécise tout ça pour que le lecteur du sujet pas au fait de toutes ces choses comprennent tout de même ).
traducteur c’est mieux que compilateur en effet x) (en js on parle de compilation quand on entend aussi obfuscation, forcément quand on fait beaucoup de natif ça dérange, je suis plutôt habitué à échanger avec les dév web ces deux dernières années x) ).
En ce qui concerne le rendu comme tu le dis il faut comparer à juste mesure ce qui est comparable, et comme j’avais dit avant il faut que je testes Pixi (je connais déjà super bien le projet ^^), le seul trucs qui m’étonnait c’était le lag sur le jeu, d’où le fait que je disait
maintenant je pense que webGL étant encore très expérimental, pas mal de chose sont instable.
Un render webGL aura très souvent une courbe de fps moins stable que canvas2D.
Je sais que en canvas2D sur mon engine j’affiche 2000 objets animé à l’écran a 60 fps sur une bonne machine (mini i5) ce qui commence à être courant, j’espère bien pouvoir grimper avec Pixi.
Quand je parlais du code du jeu, je parle de la version en ligne, avec la console tu peux voir les sources hors il n’y a du code que dans le index.html et dans code.js, d’où ma question originelle, et avec les bons termes tu comprendras sûrement mieux :
Dans code.js tu as obfusqué Pixi et l’engine ?
D’ailleurs avec quoi as-tu minimisé le code ? Grunt, r.js ? Google closure ?
Ah et une question qui me revient, le code du jeu du coup tu l’as directement écrit en JS ?
Je suis assez surpris qu’il y ai aussi peu de code en tout.
Sinon le inputtools.js me dérange un chouya, beaucoup de if d’affilé.
Pourquoi ne pas faire un objet littéral contenant les touches à l’intérieur ainsi que le code numérique associé, ainsi il suffirait de faire
if ( keys[ key ] ){ return runtimeScene.getGame().isKeyPressed( keys[ key ] ); }
Dans un jeu exporté le code est minimisé oui : J’utilise Google Closure Compiler, et je fout tout dans un seul fichier nommé code.js ( C’est à dire le moteur de jeu, le code généré depuis les évènements, et même Pixi.js ).
Par contre, si on ne coche pas la case permettant de minimiser à l’export dans Game Develop ( ou si on regarde les sources durant un aperçu ), rien n’est obfusqué et on retrouve les fichiers du moteur de jeu, avec à coté un répertoire Extensions et libs contenant aussi du code js, et enfin un ou plusieurs fichiers codeX.js contenant les évènements traduits en javascript.
( Le code des évènements traduits en Javascript est tout à fait illisible d’ailleurs, c’est de la génération automatique et ça se rapproche plus du travail d’un compilateur justement )
Alors se qui est en rouge, c’est pas un bug mais peut être un oublie…
Les paramètres de tailles et position de la fenêtre ne sont pas sauvegarder !
Par contre en noire alors là s’en est un et pas un petit !
Quand tu l’ajoute à la scène des le commencement quoi ça dis ça:
impossible d’ouvrir le fichier « CppPlatform/Extensions/PanelSpriteIcon24.png » (erreur 2 : le fichier spécifié est introuvable.)
Failed to load image from file “CppPlatform/Extensions/PanelSpriteIcon24.png”.
Ya aussi un soucis avec le petit carrer pour faire tourner l’objet en C° sur la scène qui marche pas on dirait !
Et aussi je t’en avais parlé déjà…
Mettre ici des ComboBox pour mettre oui ou non au lieux de devoir le taper au clavier dans la banque d’image
Ah et aussi que ici la fenêtre n’est pas sauver non plus niveau taille et tous !
Petite question, bien que très utile, pourquoi avoir crée l’extension Objet déplaçable et Suppression en dehors de l’écran, c’est facilement réalisable ça non ?
J’ai corrigé le message d’erreur, merci.
Pour moi le bouton pour faire tourner les objets fonctionne par contre.
Oui, mais c’est vrai que ce sont des choses dont tout le monde a très souvent besoin et ça permet donc d’accélérer la création en contre partie pour moi du maintien de cette petites extensions qui sont très très simples, donc ça va
Bin perso… moi il marche pas !
Quand je le tourne, l’image tourne que très très peut
Sinon pour le reste tu as pris note aussi ?
Je veux dire, tu compte faire de petit changement ?
Si un truc ne marche pas, tu peux m’envoyer le fichier de jeu avec les images nécessaires en me disant où est ce qu’on voit le problème.
Oui oui, je prends toujours note
Je sais que le up c’est pas très beau, mais comme je passe rarement ici et que je suis plutot discret il fallait que je le dise quelque part :
Magnifique travail 4ian, l’export redonne un regain énorme d’intérêt à mes vieux projets enfouis, je sens que la nuit va être courte ! Merci pour ce logiciel, vraiment !!!
Merci
La plateforme web ne possède pas encore toutes les extensions et fonctionnalités existantes, mais ça arrive petit à petit, et on peu déjà faire pas mal de choses en l’état
