16-06-2013, 09:07 PM
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
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
Fallback vers canvas
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.
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
Citation :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
Citation :Et qu'en est-il des smartphones qui ne supportent pas WebGL?
Fallback vers canvas
Citation :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.