Discussion :

[Camille_B]

Quand on lit ça :

Chrome est a la ramasse en terme d'interpretation de HTML5. Aujourd'hui seul firefox est capable de prendre en charge le html5 a 84%. Chrome ne le prend qu'a 69% pourtant c'est du ggogle, initiateur d'android. Va comprendre charles.

et que l'on se permet de commencer par ça :

C'est du grand n'importe quoi. Franchement, vous developpez vraimentpour le web ?

On a franchement envie de vous renvoyer à ça :

http://html5test.org

Chrome 15 : (343 pt + 13 pt bonus) / 450 => 79%

Firefox 8 : (314 pt + 9 pt bonus) / 450 => 71%

IE9 : (141 pt + 5 pt bonus) / 450 => 32%

Et je ne parle même pas du gloubi-boulga présent sur tout ce fil qui mélange allègrement HTML5, Javascript, CSS etc.

On ne fait pas du jeu vidéo avec HTML5, on fait du jeu vidéo avec un peu de HTML5 (canvas, local storage etc.) et beaucoup de javascript.

Dire qu'un navigateur ne gère que tant de pourcentage de html5 et l'autre 10% de plus ou de moins n'a donc pas de sens, tout ce qui compte c'est que le navigateur gère les parties de HTML5 utiles à la conception de jeux vidéo.

[zecreator]

D'après ce site :
http://html5demo.braincracking.org/index.php

les % sont bien différents.

Zecreator

[Invité]

Bonjour

Aujourd'hui il y a de moins en moins de respect des standarts. Tout est ouvert et chacun peut faire son flash player ou sa jvm a sa sauce. Ca n'a plus de sens. Merci l'open source.

Cela relève plus de la science-fiction que de la réalité. Je ne connais que Gnash comme implémentation libre de Flash et ce n'est pas un player Flash qui cherche à se comporter différemment de l'implémentation propriétaire si on met de côté les bogues.

Quant à Java, la JVM d'Oracle et celle d'OpenJDK partagent une grande partie du code, c'est encore plus vrai dans Java 1.7. La fragmentation des JVM ne concerne pas l'environnement desktop, cela ne touche que l'environnement mobile pour les terminaux compatibles J2ME/MIDP. Je ne vois pas du tout le rapport avec l'open source. Votre remarque est donc sans fondement.

Je ne suis pas fan des systemes proprietaires, mais je pense que l'on va droit dans le mur avec tout c es framework livres en pature a des developpeurs qui ont chacum leur "standart"'.

Vous n'êtes pas obligé d'utiliser les frameworks en question. L'écosystème Java n'a pas attendu WebGL et Canvas pour permettre la création de jeux en 3D dans le navigateur (et aussi en dehors) notamment avec des bindings d'OpenGL/OpenGL-ES dont JOGL (cf. "Zoltar's Return" de Lilian Chamontin dès 2004). C'est bien sympa la 3D sans avoir à installer le moindre plug-in mais cela va poser encore plus de problèmes que le support des applets comme une partie plus importante des couches sous-jacentes réagira de manière potentiellement différente à la fois en fonction du système d'exploitation et du navigateur malgré les jolis standards. Essayez de réécrire Minecraft en Javascript; après, on en reparlera. Je ne suis pas une mauvaise langue, je pense juste que le couple Javascript + HTML5 + WebGL manque de maturité. La situation sera peut-être bien différente dans 5 à 10 ans.

[zecreator]

La situation sera peut-être bien différente dans 5 à 10 ans.

C'est marrant, on disait la même chose... il y a 5 ou 10 ans.

[rummyworld]

bonjour,

Moi je suis convaincu qu'actuellement pour certaines catégories de jeux (jeu 2D de réflexion, d'arcade etc.), html5 est adapté pour les jeux.

Je me suis moi-même lancé dans un projet de jeu en html5...

deux exemples trouvés sur le net qui m'ont convaincu à me lancer :

- http://www.wordico.com/
- http://play.lostdecadegames.com/onslaught_arena/demo


cdt,

rummyworld

[camus3]

bonjour,

Moi je suis convaincu qu'actuellement pour certaines catégories de jeux (jeu 2D de réflexion, d'arcade etc.), html5 est adapté pour les jeux.

Je me suis moi-même lancé dans un projet de jeu en html5...

deux exemples trouvés sur le net qui m'ont convaincu à me lancer :

- http://www.wordico.com/
- http://play.lostdecadegames.com/onslaught_arena/demo


cdt,

rummyworld

Mais des jeux étaient aussi codés en BASIC sur Amstrad , ce n'est pas une question de pouvoir ou pas , bien sur qu'on peut. Sauf que quand le jeux est un business les boites ont certaines attentes , exactement comme pour la question de la balise video et audio. La il n'y a pas de "choix" technologique puisque c'est la "seule" techno disponible.Le fait qu'elle soit standard ne la rend pas efficace pour le job, c'est tout.

[h_fabrice]

Que de mots de bienvenue au HTML5 !

[davrous]

Hello,

Je me permets de faire mon petit retour d'expérience sur le sujet des jeux 2D. Je me suis amusé à porter un jeu de platforme en XNA vers HTML5/Canvas grâce à l'utilisation de la librairie EaselJS. J'ai publié un article et le code complet du jeu ici : http://blogs.msdn.com/b/davrous/arch...4-easeljs.aspx et j'ai fait 1 heure de session autour du développement d'un jeu de plateforme en vidéo ici : http://blogs.msdn.com/b/davrous/arch...-en-html5.aspx

Mon objectif était de voir si l'on pouvait faire un jeu cross-navigateur et surtout cross-devices (iPad, Android & Windows Phone 7) grâce à HTML5.

La conclusion de mes tests et recherches sont les suivantes :

- HTML5/Canvas sont parfaitement adaptés aux jeux 2D sur les desktop grâce à l'accélération matérielle présente maintenant dans IE9, Firefox, Chrome et bientôt Opera. De plus, les GPU et CPU mangent assez facilement la charge. Ainsi, mon jeu tourne sans problème à 60 fps sur mon Vaio Z équipé d'une nVidia GT330m sous IE/FF/Chrome.
- C'est nettement moins le cas des mobiles! Le même jeu tourne dans les 10 fps sous iPad 2. Il tourne un chouilla mieux sous mon Windows Phone 7 (HD7) grâce à l'accélération matérielle d'IE9 dessus mais cela reste totalement injouable!

Bref, un canvas pleine page sur les mobiles n'est pas trop envisageable aujourd'hui. Par contre, rien n'empêche de faire des petits canvas et de les faire bouger à travers CSS. C'est ce que fait Angry Birds version HTML5 si vous regardez. CSS et CSS3 transitions & animations sont en effet matériellement accélérés sous iPad par exemple. Donc mieux vaut s'appuyer dessus pour faire bouger ses sprites plutôt que de balancer tout cela dans un gros canvas. J'ai commencé à faire des tests que l'on retrouve dans mon dernier article sur CSS3 Animation ici : http://blogs.msdn.com/b/davrous/arch...ions-css3.aspx . J'aimerais bien aller plus loin en réécrivant le jeu à base de plusieurs petits canvas + animations CSS mais c'est un boulot assez important (refaire les tests de collisions, etc.).

Je pense qu'il faut du coup une couche d'abstraction qui sera apportée bientôt par des frameworks de jeux comme EaselJS pour que l'on ne se galère pas dessus. Mais je pense aussi qu'HTML5 est une belle oppornité pour les petits jeux multi-plateformes. Il faut juste faire attention de développer son jeu en partant du mobile (Mobile First comme disent les américains) puis d'ajouter d'éventuels effets en montant sur les plateformes plus puissantes.

Bye,

David

[DonQuiche]

@Davrous
Merci à toi pour ce retour détaillé.

Cela dit, j'aimerais y apporter un gros bémol. Je dispose encore ce soir d'une "veille" machine (2008) - la nouvelle arrive demain. A l'époque il s'agissait d'une configuration haut de gamme et donc vraisemblablement encore supérieure à ce dont dispose le pur casual gamer moyen aujourd'hui (c2d E6850 - et ati 5700 mais c'est le CPU qui compte ici). En fait, elle fait encore tourner sans accroc presque n'importe quelle grosse production 3D moderne avec des options graphiques en medium, voire parfois élevées.

J'ai donc testé ton jeu. Verdict : sous Firefox (dernière version, alors que le pékin moyen en est resté à la 3.x), j'ai bien 60fps la très grande majorité du temps... Sauf lors de ces quelques pics de 0,5s où l'on passe soudain à 4 ou 5 fps (20 fps affichés). Ce qui, pour un jeu de plateforme est calamiteux, les ralentissements se produisant bien sûr pile au moment où l'on ajuste le saut. Quant à Chrome (dernière version), pourtant plus rapide en général sur ce genre d'exercices, il bute à 20fps en permanence. Tous les tests ont été faits avec un PC au repos, etc.

Du coup, pour des jeux qui viseraient le casual gamer, en tout cas des gens qui ne renouvellent pas leur machine tous les 18 mois et dont le CPU n'est pas un foudre de guerre, les performances de la solution canvas me semblent au contraire totalement inadaptées pour tous les jeux réclamant une certaine fluidité (plateforme, etc).

En somme, si la limite est bien le CPU comme je le pense, l'utilisation de frameworks risque malheureusement d'empirer les choses. Je pense plutôt qu'il faut vraiment s'appuyer très peu sur le canvas, aussi peu que possible et tenir compte de cette limite dans le game design, même si c'est limitatif. Accessoirement, il doit sans doute être possible et préférable d'exécuter la logique du jeu (collisions, etc) indépendamment du système de rendu. Enfin, sous Firefox j'ai activé l'option "search as you type" ce qui m'interdit d'utiliser les touches du clavier dans des jeux en html (pas de pb avec flash par contre), un facteur tout de même très limitant.

[davrous]

J'ai donc testé ton jeu. Verdict : sous Firefox (dernière version, alors que le pékin moyen en est resté à la 3.x), j'ai bien 60fps la très grande majorité du temps... Sauf lors de ces quelques pics de 0,5s où l'on passe soudain à 4 ou 5 fps (20 fps affichés). Ce qui, pour un jeu de plateforme est calamiteux, les ralentissements se produisant bien sûr pile au moment où l'on ajuste le saut. Quant à Chrome (dernière version), pourtant plus rapide en général sur ce genre d'exercices, il bute à 20fps en permanence. Tous les tests ont été faits avec un PC au repos, etc.

Salut DonQuiche,

J'aurais bien envie de te donner une réponse trollesque en te disant de tester sous IE9/10 ;-). Plus sérieusement, il y a vraiment des différences entre les navigateurs pour l'instant à ce sujet. Cela a été illustré dans cet article : http://www.phoboslab.org/log/2011/08/are-we-fast-yet par le développeur du site de benchmark suivant: http://www.phoboslab.org/log/2011/08/are-we-fast-yet . Pour Chrome, tu as essayé d'activer l'accélération matérielle en allant dans about:flags?

Sinon, ton retour est intéressant. J'ai pourtant testé sur différentes machines mais je n'avais pas eu de différences aussi importantes de FPS. J'avais vu que pour tous les navigateurs utilisant l'accélération matérielle par défaut ou non, il faut bien faire gaffe à la qualité de ses drivers. J'ai eu beaucoup de problèmes avec des chipset ATI par exemple, donc je ne recommande plus que des nVidia pour mes démos.

Bye,

David

[DonQuiche]

Bonjour Davrous.

Oui, Chrome et Firefox bénéficient tous deux de l'accélération matérielle (j'avais déjà vérifié dans about:flags sous Chrome et about:support sous Firefox). Note cependant que ce n'est pas le cas de la majorité des utilisateurs : Do users actually get hardware acceleration ?, mieux vaut donc ne pas compter dessus. Qui plus est, mes drivers ont été mis à jour il y a un ou deux mois. Et, surtout, je n'observe de problème nul part de ce côté-ci, que ce soit en jouant à un jeu ou en lorsque je code pour OGL ou D3D, ce qui me met naturellement aux premiers rangs pour connaître les capacités de la CG de ma machine.

Toutefois, je pense que tu as tort de regarder du côté de l'accélération matérielle. Pour un jeu de cette taille, avec au plus quelques dizaines de sprites, je parie que l'on pourrait très bien faire le rendu en GDI+ avec plusieurs centaines de fps. A mon avis, on voit plutôt les limites d'un système qui n'est pas prévu pour ça à l'origine, d'un langage relativement lent et de couches empilées les unes au-dessus des autres.