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

[Seby63]

Maks, tu connais une date pour une utilisation d'ASM?

J'ai fait quelques recherche et pour le moment il n'y a pas grand chose sur le sujet... J'ai aussi vu pa mal de critique sur ASM et j'avoue que je doute aussi de cette "solution miracle".

[Maks]

Bon j'essaie de tout reprendre

Pour niahoo, il y a cet article en français : http://blogs.codes-sources.com/cyril/arc...cript.aspx En général, c'est de notoriété publique prototype > closure niveau perfs. Rien ne t'empêche de recréer un benchmark avec jsPerf

Pourquoi est-il conseillé d'utiliser la méthode prototype plutôt que la méthode closure ?

C'est principalement une question de performances. Lors de la création d'un objet "closure", le constructeur est parsé/executé, il y a donc création des différentes méthodes qui appartiennent alors à l'instance de l'objet. Avec une classe "prototype" les méthodes sont déjà instanciées lors de la création du type et appartiennent à l'instance du prototype de l'objet, deux instances d'une même classe partagent le même prototype. Cela a deux incidences :

La création de l'objet sera plus longue à cause de la création des méthodes membres.
L'instance de l'objet prendra plus de mémoire car les méthodes membres ne sont pas partagées entre les objets.

En ce qui concerne le from scratch vs framework pour le canvas, personnellement j'ai programmé from scratch (parce qu'il y a 2 ans il n'y avait pas les frameworks d'aujourd'hui, ou tout du moins pas aussi démocratisés et développés). A mon avis sans framework ça sera un peu plus rapide, uniquement si tu maitrises toutes les techniques d'optimisation ce qui n'est pas gagné. Cependant, tu seras moins productif, c'est toujours le même débat. Ca t'oblige également à connaître la façon d'animer un sprite frame par frame par exemple, le genre de trucs que le framework simplifie. Pour du pur canvas 2D ça me parait encore possible de partir sans framework s'il y a vraiment besoin de perfs très optimisées (jeu en plein écran par exemple), mais ça serait à court terme devenir dépassé techniquement.

De toute façon pour être clair, pour un jeu web en temps réel aujourd'hui : 2010 - 2013 => HTML5 Audio, Websockets (et fallbacks), Canvas
2013/2014-... => WebAudio API, WebRTC (voir websockets avec données binaires), WebGL (je mets 2013/2014 et pas 2014 parce que tout marche déjà sur chrome)

Bon ensuite sur les perfs canvas/webGL, canvas est déjà accéléré graphiquement par défaut (depuis je ne sais plus quelles versions de Chrome et Firefox), les CSS 3D également. Mais WebGL est quoiqu'il arrive beaucoup plus rapide :



Tous les détails du benchmark sont dans cet excellent article : https://www.scirra.com/blog/58/html5-2d-...e-analysis

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

Fallback vers canvas

Maks, tu connais une date pour une utilisation d'ASM?

J'ai fait quelques recherche et pour le moment il n'y a pas grand chose sur le sujet... J'ai aussi vu pa mal de critique sur ASM et j'avoue que je doute aussi de cette "solution miracle".

Non Mozilla ne l'a pas donnée.
Les critiques je ne sais pas, asm est encore à un stade peu avancé. Moi ce que j'ai vu ça m'a bluffé, surtout c'était fluide.

[niahoo]

Ah oui mais on ne parle pas de la même chose. (de plus Je n'utilise pas le mot clé new pour mes instances d'objets mais ça ne change rien). Et comme je le disais je suis conscient que ça bouffe plus de mémoire. Mais ensuite les objets sont logiquement plus rapides à utiliser. Faudra que je compare, mais la perf de création d'objet c'est bien joli mais un objet personnage par exemple tu le construis une fois, tu lui fais faire des trucs mille fois ...

---

Plus d'infos :

prototypal object creation is more than 100 times faster than functional object creation. However, when prototypal objects methods are forced to be bound to their instance, the prototypal object creation is about as fast as functional object creation ;
methods calls are always faster using functional inheritance, and binding prototypal objects methods to their instance decreases performance even more.

http://www.richard-foy.fr/blog/2011/10/3...heritance/

Comme je le disais si j'ai 10 000 objets de la même instance j'utiliserai un prototype

[Maks]

Ah d'accord je comprends mieux, après je sais pas si tu peux en tirer une hausse de performance significative. Je veux dire je doute que l'appel des méthodes puisse être le bottleneck de ton jeu.

On peut encore étendre le débat, il y a d'autres façons de créer des objets. Le défi dans un jeu c'est surtout d'avoir du code "garbage collector friendly", en gros réutiliser au maximum les mêmes objets et connaître les quelques astuces (array.length = 0 plutôt que array = [] pour vider un tableau). Ainsi on évite les baisses soudaines de FPS dues au passage du ramasse miette (profilable sous chrome).

[Seby63]

Bon alors j'ai jeter un oeil a Pixi, en réalité c'est un moteur de rendu simplement.

Il tourne sous WebGL. Si le navigateur n'est pas compatible, il passe ça sous canvas automatiquement. La prise en main est pas évidente, il n'y a pas beaucoup de doc...

J'essaye de faire un petit truc sympas et je vous montre ça.

[Xenos]

Ooook, la différence vient du buffer.
Effectivement, un GPU dessine la 2D plus vite que la 3D, mais pour la 2D, le processeur ne "nourri" pas le GPU assez vite, alors qu'en 3D, le processeur rempli le buffer de la GPU, puis il se tourne les pouces... j'ai juste?

[Maks]

Bon alors j'ai jeter un oeil a Pixi, en réalité c'est un moteur de rendu simplement.

Il tourne sous WebGL. Si le navigateur n'est pas compatible, il passe ça sous canvas automatiquement. La prise en main est pas évidente, il n'y a pas beaucoup de doc...

J'essaye de faire un petit truc sympas et je vous montre ça.

Cool Mais bon il ne faut pas trop se plaindre, WebGL from scratch c'est bien plus compliqué ^^

Mais oui pixi est assez récent il me semble. Three.js est déjà pas mal éprouvé. Mais le principe WebGL fallback vers canvas ou CSS 3D est excellent. Dans le même genre, il faudrait WebRTC => WS (pas encore vu) et WebAudio API => audio HTML5 (déjà trouvable).

[niahoo]

Perso un moteur de rendu c'est ce qu'il me faut. Un outil qui ne fait qu'une seule chose et qui la fait bien, c'est pratique, et on peut en changer facilement si on n'est plus satisfait.

Et le coup du fallback c'est cool oui

[Seby63]

Salut a tous,

Le script de base : http://je-joue-je-gagne.fr/kenji/

Puis sur sur PIXI (sans animations musique etc...) : http://je-joue-je-gagne.fr/pixi/

Sachant que le rendu peut être encore optimisé sur PIXI.

[Xenos]

... Sur PIXI, je suis à 1 FPS (et encore)...
Sur le script de base, pas de soucis (~40FPS), en mode normal (pas plein écran ni rien)