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

14

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?

Létharion
la source

Réponses:

13

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.

jhocking
la source
3
Pour être honnête à travailler sur les jeux HTML5 au cours de la dernière année en tant que travail de jour, je dirais que le navigateur qui ne prend pas en charge Canvas n'est pas assez rapide pour tout jeu décent de toute façon, mais là encore, rien de plus lent que WebKit sur les téléphones Android ... :(
Ivo Wetzel
Merci :) Je ne me soucie pas beaucoup du "support du navigateur", au moment où j'en ai appris suffisamment pour que cela compte, je m'attends à ce que le problème se soit résolu. C'est principalement pour le plaisir et l'apprentissage.
Letharion
Je fais aussi cela: le jeu lui-même est dessiné sur toile tandis que l'interface graphique se compose d'éléments DOM partiellement transparents sur le dessus.
Philipp
@IvoWetzel Je ressens la même chose ... nous travaillons aussi sur des jeux sur des plates-formes mobiles et Android est à peu près injouable ...
Vaughan Hilts
12

À 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.

aaaaaaaaaaaa
la source
2
Je n'ai pas pensé à le mentionner position:absolute, c'est un bon point.
jhocking
Le GPU Canvas n'est-il pas accéléré à un certain niveau, contrairement au DOM?
Thomas
1
@Thomas Le seul endroit où vous pouvez être sûr qu'il y a une accélération du GPU est webGL. (Techniquement, il pourrait être mis en œuvre sans, mais cela ne devrait pas se produire). Les premières implémentations 2D de canvas étaient strictement CPU, certaines fonctionnalités ont été déplacées dans certains navigateurs vers le GPU, pas dans tous les cas avec des gains de performances significatifs. Quant à l'accélération DOM GPU, ils y travaillent, et je ne vois aucune raison particulière pour que cela ne se produise pas. Dans tous les cas, ce qui importe en fin de compte n'est pas la façon dont le navigateur le fait, mais s'il fonctionne assez bien pour vos besoins, le GPU ne signifie pas toujours plus rapide.
aaaaaaaaaaaa
Que voulez-vous dire par GPU n'est pas toujours plus rapide? Sur un PC, cela peut être vrai, mais sur les plates-formes mobiles, je préférerais que le GPU fasse plus de rendu pour que le processeur ait plus de `` cycles '' à dépenser pour exécuter la logique du jeu comme l'IA, etc. De cette façon, le jeu pourrait être plus complexe .
Thomas
1
@Thomas Cela dépend de la plate-forme, du travail et de beaucoup d'autres choses. La 2D old-school est principalement des opérations de mémoire, garder les ressources dans la mémoire principale et utiliser le CPU pour ces opérations fonctionnera plutôt bien, également sur un téléphone mobile, mais essayer d'effectuer des opérations sur des données situées dans la mémoire de l'autre processeur est un tueur de performances, Donc, si vous mélangez des opérations qui ne peuvent pas être effectuées par le GPU avec des opérations GPU, vous finirez par envoyer le tampon dans les deux sens en fonction de l'opération ou vous aurez un des processeurs à écrire dans la mémoire des autres processeurs.
aaaaaaaaaaaa
6

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.

Ivo Wetzel
la source
En ce qui concerne la vitesse, basée sur une présentation vidéo du moteur Aves , lorsque vous aviez des milliers d'éléments, DOM était en fait plus rapide à gérer que le canevas. Êtes-vous en désaccord? Cela a-t-il changé? J'aimerais pouvoir retrouver cette vidéo ...
Letharion
1
: DI travaille Zynga, avec le gars qui a fait Aves. Les choses ont changé l'année dernière, croyez-moi :)
Ivo Wetzel
-1, j'ai essayé d'avoir ~ 100 000 éléments dom pour une application non-jeu, cela n'a pas fonctionné. Mais quelques milliers d'éléments ne sont pas problématiques. Ce n'est pas comme si la toile allait être rapide si vous y dessinez plusieurs milliers d'images à chaque mise à jour.
aaaaaaaaaaaa
@eBusiness Alors allez-y et introduisez l'ordre Z complexe et les transformations 3D. Bonne chance avec ça :)
Ivo Wetzel
4
@IvoWetzel Si vous voulez faire de la 3D, la toile est le choix. Mais ce n'est pas ce que dit votre réponse, alors quel est votre point?
aaaaaaaaaaaa
2

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!

Zoyt
la source
2

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).

Par Aronsson interrogé
la source
2

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.

d13
la source
1

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.

copie
la source
Depuis quand DOM a-t-il de mauvaises performances. Ce n'est pas accéléré par le matériel, c'est la seule différence. Et une table 500x500 en couleurs d'arrière-plan sur la cellule n'est pas une implémentation DOM efficace
Raynos
1
@Raynos J'ai remarqué que ce n'est pas une implémentation DOM efficace. Il n'y en a pas si vous voulez manipuler des pixels.
copie du
1
-1, les grandes tables sont un tueur de performance. Canvas est certainement le meilleur outil si vous souhaitez manipuler des pixels individuels, bien que le configurer contre une implémentation DOM aussi pauvre rend vraiment votre exemple inutile. Hors de la hanche, mon meilleur coup à une implémentation DOM de ce serait 50000 divs 5x1 avec 32 images d'arrière-plan différentes permutées au besoin.
aaaaaaaaaaaa
@eBusiness ouais, les gens me l'ont déjà dit. Dommage que je ne l'ai pas compris par moi-même à l'époque: - /
copie le
@Raynos, DOM n'a jamais été rapide. En fait, l'une des principales raisons du canevas est que le DOM est lent.
EN RELATION