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

[niahoo]

Et bien pour les perfs je veux bien le benchmark oui parce que à mon sens les fonctions sur les objet construits en closures sont directement liées à l'objet, il n'y a pas de lookup à faire dans le prototype (voire dans une chaine de prototypes). ça coûte juste plus de RAM mais ça c'est ok pour moi, on parle généralement de quelques objets (genre des personnages). Si j'ai 10 000 objets j'utiliserai naturellement un prototype. (ou du moins je testerai les perfs des deux).

Pour la "way to go", si je m'en réfère au livre de Douglas Crockford, il conseille plutot l'héritage par fonction plus que celle par prototype. Donc moi je dis : sources !

[Argorate]

Je vois pas comment une surcouche (framework) peut être plus rapide que du natif... intox?

[niahoo]

j'ai pas regardé ce framework mais disons que si le framework utilise de bonnes pratiques ça peut être plus performant que du code natif. D'autant plus que tu lui passes des paramètres, etc, il va logiquement créer des fonctions d'appel à du code natif, ce n'est pas parce que tu passes par le framework que chaque appel de l'API passe par quarante fonctions. Surtout en javascript ou les paramètres sont gardés dans une closure construite pour l'occasion qui sera simplement appelée ensuite.

Là dessus, le framework peut automatiquement utiliser du cache, de la 'memoization', etc...

[Seby63]

Hey, vous auriez pu me dire que mon code était relativement faux ^^

Nouvelle version de test et la forcement ça change tout... : http://jsperf.com/canvas-drawtiles-vs-ca...awbuffer/2

Je monte a 263.xxx op/sec en 1024 avec chrome et 13.xxx en 800? Bizard...

Les autres navigateur restent quand même aux alentours des 6000/10 000 op/sec avec le rendu image sans redésinné les tiles. On vois d'ailleurs bien la différence entre le rendu image et la fonction qui permet de redésinné les tiles.

---

Pour ce qui est de la rapidité des bibliothèques, c'est plus rapide que tu code natif car la lib utilise forcement un système d'image de rendu.

Il crée le cercle, le stoque, et l'affiche a chaque boucle. Donc forcement un gros gain de temps, plutôt que de nettoyer, crée un nouveau cercle, l'affiché...

La fonction pourrait être repris par du code natif afin d'obtenir des résultat égal je pense. (Je vais essayer de faire le test).

---

Voilà la résultat des tests : http://jsperf.com/canvas-lib-render/16

On peut voir que le code natif est supérieur aux autres lib. Pourquoi? Par ce que le système actuel recherche uniquement si le rond a bougé ou non. Si celui-ci a bougé, le context "vidé" puis redésinné.

Le canvas est rafraîchi uniquement quand il y a du changement.

[Seby63]

Je ne connais pas, je vais jeter un coup d'oeil
Si je devais refaire un moteur de jeu aujourd'hui je prendrais un framework WebGL qui fallback vers canvas (three.js ou pixi.js)
oxman avait linké Turbulenz, ça a l'air excellent mais je me demande si c'est surtout pas du aux designers qui sont bons

Pourquoi utiliser WebGL pour la réalisation d'un moteur en 2D iso?

[Sephi-Chan]

Parce que l'API est très performante (car accélérée par l'éventuelle carte graphique).

[Xenos]

Mais, les cartes graphiques aussi ont des accélérations 2D, non? Que les navigateurs peuvent potentiellement utiliser...
Google Chrome a même une option qui permet d'activer l'accélération 2D du GPU.

[Seby63]

Je pense qu'après c'est un choix. Utiliser WebGL pour un rendu 2D ne vaut pas vraiment le coup a ce que j'ai pu lire.

[Maks]

@niahoo je te retrouve ca des que je suis sur mon pc
Des fois on pense que le moteur JS aura plus de boulot alors qu'en fait c'est assez optimise pour que ca soit l'inverse, j'avais deja vu un exemple etonnant a ce sujet je vais retrouver ca.

Pour webgl je vais detailler aussi mais les perfs sont tjs superieures a canvas 2D. L'acceleration graphique est deja activee par defaut sous chrome et FF.
A noter que three.js est meme capable de faire du css 3D.
Aussi le plus rapide a l'avenir sera de programmer le moteur de jeu en C/C++ et compiler vers JS + asm

[Xenos]

Et qu'en est-il des smartphones qui ne supportent pas WebGL?