Développer un jeu avec Javascript et Canvas : The no tears way

[Maks]

Base de travail (EN) : http://www.html5rocks.com/en/tutorials/c...otearsgame

Base de travail possible (FR) http://www.siteduzero.com/tutoriel-3-470...anvas.html => utiliser prototype plutôt que les closures, un manager plutôt que new Image(); .onload .src etc...

=> Manager d'images pour être sûr que vos images sont chargées et prêtes à être dessinées dans le canvas : http://www.html5rocks.com/en/tutorials/g...etmanager/

Un exemple de jeu complet pas à pas : http://io-2011-html5-games-hr.appspot.com/#1

Améliorer les performances de Canvas (indispensable) : http://www.html5rocks.com/en/tutorials/c...rformance/

Code :

// Pre render Canvas divise le temps mis par la boucle de dessin par 10... LE truc à savoir sur Canvas
// on créé un canvas hors écran qu'on n'ajoute pas au DOM
var buffer = document.creatElement('canvas');
// on récupère le context
var ctx = buffer.getContext('2d');
// vous dessinez dans ce canvas
ctx.fillRect();
ctx.drawImage();
[...]

// on récupère le context du canvas à l'écran
var canvas = document.getElementById('canvas');
var ctx2 = canvas.getContext('2d');

// boucle de dessin, setInterval ou requestAnimationFrame
setInterval(funtion { draw(buffer, ctx2); }, 1000/60); // 1000/60 = 16,666 = 60 FPS
// on envoie le canvas hors écran et le context à l'écran

function draw(buffer, ctx2) {
        ctx2.drawImage(buffer, 0, 0);
        // ici dessin des personnages par exemple
}

Canvas et Web Workers : http://weblog.bocoup.com/processing-pixe...eb-workers

RequestAnimationFrame pour gérer votre boucle de dessin : http://lmlt.fr/2011/06/05/la-boucle-prin...tionframe/

Jeu XNA vers Canvas grâce à EaselJS : http://blogs.msdn.com/b/davrous/archive/...seljs.aspx

Questions/Réponses pointues sur JS et Canvas : http://stackoverflow.com/

Valider son JSON pour les maps : http://jsonlint.com/

Et de solides connaissances en JS, parce que HTML5 c'est 1% de HTML et 99% de JS

[quentin01]

Hum ... J'aurais quelques critiques à formuler sur ce que tu as dit. Déjà sur RequestAnimationFrame que tu as cités, cette techno' n'étant encore vraiment pas prêt à l'utilisation, ses performances sont trop ... Hum ... Aléatoire ! Il est normalement censé figer le nombre de frame, en adaptant les pauses entre les deux tours de boucles, mais il n'est pas encore assez au point et son utilisation est encore hasardeuse. Si j'aurais rédigé à te place ce post je l'aurais soit spécifié qu'il est encore trop instable ou alors je ne l'aurais carrément pas cité.

D'ailleurs ton histoire de buffer est pas forcément clair pour tous le monde, j'ai au début cru que la boucle d'affichage faisait aussi boucle de jeu et qu'après les deux sont séparés. Mais je me trompais sur toute la ligne, le buffer sert juste à bufferiser une seule image que l'on affiche ensuite dans le canvas affiché. Sauf qu'à mon avis si le nombre d'images va croissant les performances seront pas forcément au rendez vous vu qu'il faudra stocker un élément DOM qui est surement plus lourd qu'une simple image.

Sinon je trouve le reste des articles et des informations pertinentes et intéressantes.

[niahoo]

Même si le nombre d'images augmentes il sera quand même plus rapide de copier les images stockées en RAM plutot que de les regénérér à chaque boucle !

[quentin01]

Le stockage abusif de données dans la RAM n'est pas forcément des plus rapides si ses données sont volumineuses et beaucoup.

[niahoo]

Je ne vois rien d'abusif là dedans ... vu que tu stocke quelque chose qui ne bouge pas, c.a.d le background + quelques objets dessus, en 4 ou 5 exemplaires, ben ça te fait pas grand chose, et ça fait 5 fois la taille de ton canvas, et tu devrais quand même le calculer à chaque itération donc le stocker quand même.

Au lieu de vider/replir ta RAM tout le temps tu la laisses un peu statique, je ne vois pas le problème.
Ensuite si tu stockes 3 000 canvas dedans ok.

Bon je dis ça, je ne connais pas les mécanismes internes et je n'ai pas expérimenté mais ça me paraît logique.

[Maks]

Hum ... J'aurais quelques critiques à formuler sur ce que tu as dit. Déjà sur RequestAnimationFrame que tu as cités, cette techno' n'étant encore vraiment pas prêt à l'utilisation, ses performances sont trop ... Hum ... Aléatoire ! Il est normalement censé figer le nombre de frame, en adaptant les pauses entre les deux tours de boucles, mais il n'est pas encore assez au point et son utilisation est encore hasardeuse. Si j'aurais rédigé à te place ce post je l'aurais soit spécifié qu'il est encore trop instable ou alors je ne l'aurais carrément pas cité.

D'ailleurs ton histoire de buffer est pas forcément clair pour tous le monde, j'ai au début cru que la boucle d'affichage faisait aussi boucle de jeu et qu'après les deux sont séparés. Mais je me trompais sur toute la ligne, le buffer sert juste à bufferiser une seule image que l'on affiche ensuite dans le canvas affiché. Sauf qu'à mon avis si le nombre d'images va croissant les performances seront pas forcément au rendez vous vu qu'il faudra stocker un élément DOM qui est surement plus lourd qu'une simple image.

Sinon je trouve le reste des articles et des informations pertinentes et intéressantes.

Bien sûr il n'y a aucun problème, c'est pour cela que j'ai ouvert ce topic

RequestAnimationFrame n'est en effet pas au point, il y a d'ailleurs les préfixes -moz-, -webkit- etc qui nous l'indique Sur Firefox je n'arrive pas à figer le FPS à 30 d'ailleurs, il semble ne pas prendre en compte la valeur de l'intervalle... Je le cite parce que de toute façon, rien n'est encore figé dans toutes ces nouvelles possibilités. Par ailleurs, dans le cas d'un MMO, arrêter de dessiner le canvas n'est pas intéressant c'est pour cela que je ne l'utilise pas. Mais pour un RPG, ça peut donner une forme de pause bien pratique

Pour le buffer j'ai mis longtemps à comprendre aussi, en fait c'est tout bête une fois que tu as saisi le truc. Le code que j'ai mis est là pour tenter d'expliquer. Mais grossièrement comme tu l'as dis, on créé un canvas où l'on va dessiner, on ne l'ajoute pas au DOM, et avec la méthode drawImage(); on peut dessiner un canvas dans un autre canvas car le canvas va être considéré comme une image. Il va donc être mis en cache. Ca sera une bête image en cache en fait

Et niveau performance c'est 10 fois plus rapide, profilage IE9 (ou Chrome) à l'appui

---

Tuto pour la pseudo 3D avec Canvas, comme la démo du FPS de Ben Joffee pour ceux qui se souviennent (http://www.benjoffe.com/code/demos/canvascape/textures)

http://dev.opera.com/articles/view/creat...l-5-can-1/

[niahoo]

Pour dis tu que c'est inutile pour un MMO mais efficace pour un RPG. De quelle différence entre ces deux types de jeux parles-tu ?

[Maks]

Si tu veux RequestAnimationFrame va mettre en pause ton jeu lorsque tu vas changer d'onglet donc c'est intéressant pour un jeu solo. Mais pour un jeu persistant comme un MMO qui doit tout le temps être mis à jour je pense pas que ça soit très intéressant ?

[niahoo]

HMm si tu changes d'onglet tu t'en fous que ce soit mis en pause puisque tu regardes pas, non ? Et quand tu reviens ben c'est mis à jour donc je ne vois pas la différence !

[Maks]

Tu as peut être raison, le code JS côté serveur va continuer à s’exécuter et peut être qu'en revenant sur l'onglet le canvas se rafraichirait correctement en fonction des nouvelles coordonnées.

Mais j'ai un doute quand même car dans mon esprit je ne pensais pas faire ça en fonction de coordonnées mais plutôt en terme de déplacement.
Je m'explique pour que mes personnages se déplacent il y a une animation de déplacement. Donc j'avais pensé à un schéma genre :

Le joueur 1 décide de se déplacer
On envoie au SSJS cet évènement et on déclenche l'anim de déplacement
Le SSJS met à jour une DB
Le SSJS permet au joueur 2 que le joueur 1 veut se déplacer
On déclenche l'anim de déplacement sur l'écran du joueur 2

Du coup si je bloque la boucle de dessin quand je vais revenir sur l'onglet ça risque de ne plus ressembler à grand chose