To Canvas, ou pas To Canvas, lors de la création de jeux basés sur un navigateur?

Contexte: J'ai une longue expérience en développement, mais la dernière fois que j'ai codé un jeu, c'était il y a plusieurs années. Mes compétences Javascript sont assez limitées, et j'ai l'intention de les améliorer en construisant un jeu simple - Tetris, Pac-man ou quelque chose de ce niveau de complexité.

Question: Il me semble qu'un choix fondamental que je dois faire est de savoir si je dois rendre sur un <canvas>élément ou non.

Avec un canevas, j'ai des outils de base pour rendre des points, des lignes et des choses plus complexes en plus. Vraisemblablement, il existe, ou existera, divers cadres pour y contribuer.

Sans canevas, je pouvais garder mes objets dans l'arborescence DOM, comme une page Web ordinaire, seulement assez complexe, avec de nombreux éléments qui se chevauchent.

Une approche est-elle meilleure que l'autre? Sont-ils mutuellement exclusifs? Comment savoir lequel choisir?

Canvas et DOM ne s'excluent pas mutuellement, bien qu'ils soient assez séparés. Une bonne approche serait de rendre la zone de jeu principale (par exemple, les pièces qui tombent dans Tetris) en utilisant Canvas, et de faire toute l'interface utilisateur (par exemple, l'affichage des scores) avec des éléments DOM qui chevauchent l'élément canvas.

Cela dit, une telle approche n'est pas vraiment nécessaire pour un jeu primitif comme Tetris. Canvas est utile pour des effets graphiques plus avancés, mais si ceux-ci ne sont pas nécessaires, le fait de coller au DOM vous donnera une compatibilité plus large; tous les navigateurs ne prennent pas en charge HTML5 Canvas.

À propos de DOM
DOM fonctionne plutôt bien pour la 2D à l'ancienne, ce qui signifie qu'il n'y a pas de rotation ni de mise à l'échelle de l'image. Il existe en fait des outils pour ces deux emplois, mais vous ne pouvez pas compter sur leur bon fonctionnement.

Pour un jeu, vous devez vous fier le moins possible au moteur de mise en page du navigateur, c'est-à-dire utiliser position:absolutepour placer des objets. Essayez autant que possible de ne pas créer et détruire des objets DOM tout le temps, si vous avez besoin d'un nombre très variable d'objets, vous voudrez peut-être un pool d'éléments DOM inactifs display:none, prêt à être réactivé si nécessaire.

DOM vs canvas
Avec la part de marché de IE8, le rétrécissement du canvas devient une option de plus en plus attrayante, pour la plupart des jeux, c'est probablement un bon choix. Mais pour certains travaux, DOM est l'outil le plus facile à utiliser, vous pouvez utiliser un flux de documents si nécessaire, vous pouvez attraper les clics directement par l'objet rendu, il est facile d'intégrer des barres de défilement.

Il est difficile de couvrir la différence de performances, cela dépend du travail et varie énormément d'un navigateur à l'autre.

Cela dépend complètement du type de jeu, bien que la toile s'adapte à "la plupart" d'entre eux.

La gestion DOM devient horrible à un certain moment, plus vous obtenez d'éléments plus lentement, plus vous vous déplacez EXTRÊMEMENT PLUS LENTE.

La gestion de l'ordre de chargement des actifs avec les éléments IMG est ... non-trival (intercepter les erreurs sur les protocoles délibérément cassés sur les balises d'image: D).

Bien que, pour les jeux avec des images principalement statiques et un faible nombre d'effets, j'irais quand même avec DOM. Tout le reste, la toile est le premier choix (trucs de pointage et de clic, bien que les hitmaps soient une histoire différente).

La toile est si rapide de nos jours (même sur iPhone), il n'y a pratiquement aucune raison de ne pas l'utiliser.

Si vous créez un jeu HTML5, la toile est de loin meilleure. Voici pourquoi:

1. Vitesse - Considérez la toile comme une image. Vous dessinez sur l'image, puis elle oublie ce que vous avez dessiné. Cela augmente considérablement les performances par rapport à DOM ou SVG. Les applications DOM et SVG font le suivi de chaque objet que vous placez à l'écran. Cela signifie que si vous avez un grand niveau avec de nombreux objets à l'écran, en particulier hors écran ou cachés, ceux-ci sont dessinés et conservés de toute façon.
2. Fonctions de dessin - Bien que les éléments DOM aient de puissantes transformations CSS3, ce n'est rien comparé aux fonctionnalités du canevas. La toile peut dessiner n'importe quel objet, avoir un support de dégradé puissant, des plugins pour afficher des objets en 3D, des filtres, etc.
3. Prise en charge - Lorsque vous utilisez le DOM, lorsque vous souhaitez utiliser des fonctionnalités expérimentales telles que des transformations ou des animations, vous devez utiliser les préfixes -moz-, -webkit-, -o- et -ms- en CSS. Dans la toile, vous n'avez pas à vous en préoccuper. Dessinez simplement avec une fonction, et vous avez terminé. Un autre avantage lié au support du canevas est la façon dont votre application s'affiche. En tant que développeur de site Web, le manque de normalisation DOM entre les navigateurs me rend fou. Les arrière-plans, les dégradés, les transformations, etc. s'affichent différemment d'un navigateur à l'autre, malgré les spécifications détaillées du W3C. Dans le canevas, je n'ai rencontré qu'une seule chose qui pourrait être différente: les arrière-plans. Lors de l'affichage d'un arrière-plan en mosaïque, certains navigateurs prennent "tile-x" comme centre de la tuile à 0px sur l'axe des x, et d'autres le prennent comme simplement la tuile vers le bas.
4. Bibliothèques et documentation - Il y a des TONNES de grandes bibliothèques sur les documentations pour faire des jeux avec la toile. Certaines bibliothèques: CreateJS, paper.js, fabric.js, KineticJS, libCanvas, Processing.js, PlotKit, Rekapi, PhiloGL, InfoViz Toolkit, Frame-Engine, CAKE, Raphaeljs, Tweenjs, etc. Je pourrais en énumérer une tonne de plus, mais il est inutile.

Inconvénient - Animation - Bien qu'il existe de nombreuses bibliothèques d'animation, j'adore les animations CSS3. Ils sont si faciles à créer, à manipuler et à déclencher. Il existe différents hacks pour faire fonctionner les animations CSS3 avec des objets avec le canevas, mais je pense que la plupart des gens préfèrent ne pas utiliser cette méthode.

Bonne chance avec ton jeu et j'espère voir ce que tu fais!

Si vous envisagez de cibler les navigateurs mobiles, en particulier Android, et que le jeu contient des graphiques en mouvement, évitez l'animation DOM. Le navigateur de stock d'Android est inutile, même s'il s'agit d'un webkit. Consultez ce fil de discussion Android avant de commencer: "Rendu terrible des animations CSS3 et Javascript dans le navigateur et WebView" .

Le canevas en lui-même n'est peut-être pas plus rapide, mais il existe des cadres pour invoquer l'accélération matérielle pour les animations de canevas, par exemple CocoonJS . Il y a un lien vers une vidéo sur le site, montrant les gains de performances que vous pouvez réaliser en utilisant le framework (mais je ne suis pas autorisé à publier plus de deux liens, pour une raison quelconque).

Réponse simple: WebGL avec repli de canevas.

Réponse nuancée: si votre jeu contient beaucoup de texte, superposez une couche de texte HTML. Pixi.js est un cadre d'affichage éprouvé avec des extras utiles qui fonctionne bien pour cela.

Rappelez-vous que DOM signifie modèle d'objet de document . Vous voudrez l'utiliser pour créer des jeux uniquement dans des situations très rares et préférez la toile dans la plupart des cas.

Même si votre jeu a de petites exigences graphiques, le faire dans DOM aura de mauvaises performances; rien de plus que Tetris ne fonctionnera probablement mal.

J'ai un exemple réel: lorsque j'ai créé une implémentation de Game of Life de Conway, j'ai commencé avec une table 500x500, changeant la couleur d'arrière-plan des cellules. Dans cette version, un planeur ne fonctionnait pas à plus de 30 images par seconde, des motifs plus grands en résultaient à peine plus de 1. Dans ma version toile de ce jeu, il est maintenant possible d'exécuter des patters beaucoup plus gros (population de 1000 et plus) en douceur à ~ 30 ips.

En outre, cela devrait également être le cas pour SVG (Scalable Vector Graphics), même si je n'ai jamais essayé cela en pratique.

Edit : je dois admettre que mon exemple n'est pas très bon (car tables = mauvais). Mais le point principal est toujours vrai: la manipulation DOM est pour les documents. Le navigateur doit rechercher du CSS et allouer plus de mémoire lorsque vous travaillez sur des éléments. Cela n'a pas vraiment de sens d'être plus rapide que la toile.