Discussion :

[jean_kevin_musclor]

Bonjour,

Je teste un peu le javascript-html5 pour voir si ça serait intéressant de tenter de faire des jeux avec.

Je bute sur un premier problème, le gros problème des performances cpu, parce que les browser c'est un peu optimisé à la truelle et donc pas vraiment conçu pour faire des jeux vidéo...

Voilà un résumé de mes premières expérimentations, pas vraiment concluantes...

- expérimentation 1: gros pixel en canvas 2d stretché. Résultat catastrophique, le stretching software met le processeur à genoux.

- expérimentation 2: faire tourner 12 triangles webgl. performances vaguement acceptables sur chrome (mais ça reste du cpu-killer par rapport aux plugins unity ou flash), par contre sur iexplorer/firefox c'est la méga catastrophe ils boulent un max de gpu alors rendu émulé tellement lent que ça me pompe 100% du cpu pour ramer à 30 fps.

Là je suis très démotivé pour poursuivre les expérimentations plus loin... j'ai l'impression de revenir au quickbasic avec le fullscreen et la vsync en moins...

Bon apparemment je suis pas du tout parti dans la bonne direction... il doit bien exister des techniques pour optimiser du javascript-html5 mais j'ai pas trouvé.

[jean_kevin_musclor]

Je viens de trouver une possibilité de piste d'optimisation pour la 2d...
il semblerait que le stretching est plus rapide quand il est fait avec drawImage() qu'en laissant le navigateur le faire tout seul.
je dis ça, mais il faut que je fasse des tests plus précis

[jean_kevin_musclor]

Bon puisque je suis en train de tester je remonte (ça peut intéresser) la qualité du retracage sur windows 7:

- chrome: vsync sur les deux modes
- iexplorer: vsync en mode aero, saccade régulière en non-aero
- firefox: saccades immondes sur les deux modes (est-ce que ça vient de firebug ? chai pas...) que j'arrive parfois à annuler en tripotant avec la souris et là donc c'est fluide, bref j'ai rien compris à leur bazar

Bon mais évidemment là je test sur un pc... sur un mobile de toutes façons ça va ramer car je n'ai toujours pas trouvé comment accélérer le traçage.
A priori si on est logique c'est pas possible, puisque si je fais un stretch ça nous fait un tracé supplémentaire donc ça sert strictmeent à rien d'optimiser d'un côté le blitting en basse résolution si c'est pour reperdre du cpu en fin de pipeline avec un tracé stretché...

Bon donc conclusion des tests, à la date actuelle:
- html5 commence à être approximativement prêt pour les jeux 2d sur desktop, sur mobile tant pis
- html5 n'est pas prêt pour les jeux 3d

[MoDDiB]

Faut peut être plutôt creuser par là :
http://arstechnica.com/gaming/2013/0...n-the-browser/

[jean_kevin_musclor]

Déjà testé, ça m'a crashé la machine.

Du coup ils ont remplacé leur demo par ça: https://www.unrealengine.com/html5/

Techniquement c'est déjà beaucoup mieux, ça se contente de me crasher le navigateur.


Sinon à part ça la version flash de la citadel marche très bien.

Bref c'est ce que je dis, html5 est pas prêt de remplacer les plugins. Si actuellement 99% des jeux browser pro sont faits avec flash/unity, c'est qu'il y'a une raison.

Tout ce que j'arriverais à faire pour l'instant avec l'html5 c'est un pacman. La question est de savoir si ça vaut le coup, c'est peut-être plus intelligent de faire d'abord un pacman natif avec sdl qui puisse donner des version mobile propres, et puis pour l'option browser je verrais plutôt du cross compile crossbridge que emscripten.

Si je fais ça en javascript ça sera de toutes façons trop lent pour les mobiles, le seul intérêt qu'on pourrait entrevoir dans le javascript c'est que c'est théoriquement plus facile à programmer que du c++, mais en fait c'est même pas vrai vu que pour retrouver les effets d'animation de palette en canvas 2d va falloir me casser la tête à trouver des bricolages tordus alors qu'en c++ je suis libre de colorier chaque pixel comme je veux, donc, je sais pas encore si je vais faire joujou avec le javascript, je suis pas sûr que ça vaille le coup.

[MoDDiB]

Etonnant j'avais pu tester la démo à sa sortie.
Normalement la version 5.0 de unity qui devrait arriver dans moins d'un an aura un export web en html 5 ( donc plus besoin de plug in ).
D'ailleurs il y a un test disponible là et sous chrome ça fonctionne plutôt pas mal : http://blogs.unity3d.com/2014/04/29/...hing-in-unity/

C'est donc que techniquement il doit y avoir moyen de faire tourner tout ça rapidement.

[Fusoy]

Le logiciel Construct 2 arrive a faire des bons résultats en HTML 5. Tu peux peut-être leur demander les grandes lignes de leur techniques d'optimisations.

[jean_kevin_musclor]

Pas mal construct 2 le résultat est intéressant... c'est de la 2d et ça fonctionne pas trop mal.

si je me lance dans un moteur javascript ça devrait être de la 2d

[jean_kevin_musclor]

Bon alors finalement j'ai refait des tests de stretch car bosser en basse résolution peut être utile pour plein de choses (par exemple alléger des opérations de blitting compliquées).

Bon donc, le stretching css est un cpu-killer il ne faut surtout pas l'utiliser. Il faut passer par un context.drawImage(canvasresolutionpourrie,1024,768) à la place.

[jean_kevin_musclor]

Bon donc, fin des tests,
La solution la plus optimisée c'est de faire un tracé simple à echelle 1, un arrière-plan et quelques sprites.
Stretcher une basse résolution n'a d'intérêt que pour des routines de tracé complexes (plein de calques et d'objets, particules, manipulation de pixels, émulation, etc).

[jean_kevin_musclor]

J'ai repris les tests, maintenant je tripote les compileurs c++ emscripten et cheerp.

C'est assez rustre ces traducteurs automatiques... ça compile le c+ en assembleur et re-traduction en javascript, ils ont reproduit les jump avec des case break horribles, bon, ça explique pourquoi c'est plus lent que du javascript natif.

Le problème principal va donc consister à essayer de comprendre quelque chose à cette bouillie illisible pour attraper la fin de pipeline graphique car cet endroit là doit être optimisé.

[jean_kevin_musclor]

Maintenant je tripote les buffers audio... le stream avec trois buffers ça fonctionne pas, y'a apparemment que le buffer statique qui fonctionne. Et puis ça marche pas sur iexplorer, et sur firefox y'a du deprecated. Bon bref la sortie audiobyte directe ça va pas être possible pour l'instant il vaut mieux utiliser bêtement les objets sound.

[jean_kevin_musclor]

Test non concluant sur cheerp. Il n'est pas capable de caster les pointeurs... je retourne sur emscripten.

[jean_kevin_musclor]

Emscripten est mieux, le code est super lisible donc il est facile de le retravailler pour optimiser la sortie de pipeline.

[jean_kevin_musclor]

Aujourd'hui j'ai testé un peu de webgl, en fait il y'a moyen d'obtenir un 30 fps décent sur iexplorer et autres navigateurs avec rendu émulé, si on lui demande pas trop: éviter de tracer plus de 2000 polygones, et résolution du genre 320*240.

j'ai l'impression de retourner au msdos...

[yetimothee]

Salut,

y a moyen d'utiliser les vbo et les techniques "modernes" (shaders etc) d'OpenGL avec webgl ? Si t'as pas essayé ça c'est normal que tu ne puisses pas afficher plus de 2000 polygones (le mode immédiat avec le pipeline fixe c'est complètement obsolète).

Dès que tu auras finis tes expérimentations, feras-tu un compte rendu un peu plus détaillé des comparaisons ?

Bon tests !

[jean_kevin_musclor]

Ca n'a rien à voir avec le pipeline d'opengl, là où j'ai des basses perfs c'est sur le rendu émulé (qui rend tout avec le cpu donc et pas avec le gpu), ce qui consomme 99.999 % cpu c'est le fragment shader dès qu'il doit gérer plus d'une texture.

La bonne façon d'optimiser ça c'est donc les techniques à l'ancienne: baisser la résolution, précalculer le multitexturing, eliminer les faces occluses, etc.

[yetimothee]

C'est pas vraiment de l'OpenGL quoi ?

[jean_kevin_musclor]

Effectivement, sur windows, sous le capot du webgl en réalité c'est du directx qui tourne.

[I_Pnose]

Aujourd'hui j'ai testé un peu de webgl, en fait il y'a moyen d'obtenir un 30 fps décent sur iexplorer et autres navigateurs avec rendu émulé, si on lui demande pas trop: éviter de tracer plus de 2000 polygones, et résolution du genre 320*240.

j'ai l'impression de retourner au msdos...

T’as de meilleures perfs en émulé que si tu passais par le GPU ? C’est un peu étrange comme comportement. T’as testé sur plusieurs machines ?

Je n’ai jamais touché à webgl mais il m’est déjà arrivé de lancer quelques petites démos par curiosité et ça tournait plutôt pas mal de souvenir (il y avait peut-être de gros cache-misères, j’en sais rien, mais c’était fluide).

Edit : Du genre cette démo, elle tourne comment chez toi ? Si t’as le framerate d’un powerpoint y’a sans doute un souci de pilote ou que sais-je (j’ai un 60fps solide de mon côté avec une machine plus que modeste).