Discussion :

[I_Pnose]

à peu près 15 fps chez moi

Tu as tenté, par curiosité, de passer en OpenGl natif histoire de voir si tes perfs étaient vraiment dues au navigateur ou à autre chose ? Par défaut Firefox (et Chrome aussi il me semble) passe par une implémentation de OpenGL ES spécifique (nommée Angle) qui redirige tous les appels vers DirectX 9. Cette implémentation entraîne peut-être des soucis chez toi, qui sait.

Pour vérifier, il est possible de se passer de cette couche et d’attaquer OpenGL directement ; Sous firefox tu fais about:config dans la barre d’adresse et tu cherches le paramètre webgl.prefer-native-gl (par défaut il est certainement à false). Sous chrome je ne sais pas, mais c’est certainement faisable également.

[Traroth2]

ma machine fait tourner impeccablement les jeux genre doom3 et je n'ai pas besoin de plus pour faire de l'internet, et quand on verra le même genre de rendu dans webgl les poules auront des ratiches. dual core 2*3giga et carte pixel shader 3, fait tourner sans problème des dizaines de milliers de poly dans le frustum avec shaders parallax bump shadow physx etc... mais pas avec webgl

mettez un peu les mains dans l'opengl c++ vous allez voir la différence de perfs avec webgl
mais c'est sûr que si tu prends pas la peine de comparer tu peux pas savoir

Oui, mais comment tu expliques la différence de performance perçue entre toi et tous les autres commentateurs ? C'est plutôt bizarre, non ?

Au fait, Doom 3, c'est un jeu de 2005...

[jean_kevin_musclor]

Tu as tenté, par curiosité, de passer en OpenGl natif histoire de voir si tes perfs étaient vraiment dues au navigateur

OUI
je me base pas sur des rumeurs internet pour faire mon avis
je mets les mains dans le cambouis avant d'affirmer des trucs

[I_Pnose]

OUI
je me base pas sur des rumeurs internet pour faire mon avis
je mets les mains dans le cambouis avant d'affirmer des trucs

Je n’ai pas avancé le contraire... d’ailleurs je n’ai rien avancé, j’ai simplement posé une question. Je cherchais juste à comprendre pourquoi avec ta config modeste tu obtenais les mêmes perfs que moi avec une tablette x86 équipée d’un Intel Atom et son chipset graphique ridicule.

[TiranusKBX]

Pour moi WebGL est un truc qui rame sous firefox et un truc qui ne se lance pas sous Chrome car j'ai désactivé l’accélération physique vus que ça me faisait plein de fenêtre noires ^^

[Jbx 2.0b]

Pour avoir joué avec Shadertoy sur différentes machines et navigateurs, le constat c'est souvent :

- Firefox prend deux heures à charger la page de garde.
- IE s'emmerde même pas à essayer.
- Chrome ça marche à peu près, jusqu'au beau matin ou il te dit que ta version n'est pas la bonne.
Et je répète quelque soit la machine (i7/GTX580 chez moi, Xeon/Quadro 4000 et core 2 duo/Radeon HD3450 au taf).

Alors oui, y a surement moyen de régler deux trois trucs pour optimiser ou réactiver le support GL, mais delà à ce que madame michou profite de la 3D temps réel sur son navigateur, c'est pas pour aujourd'hui.

Et question perf, bah faut être franc, c'est mauvais. Pour avoir développé un clone (partiel) de shadertoy en natif, en C++ (dispo ici, que en Win 64 bits disoulé), on voit clairement la différence. Et encore mon code est loin d'être opti (je reste un amateur, et l'interface Qt en transparence par dessus le shader coûte bonbon). Et ici, la seule geometrie que l'on transfert au GPU, c'est deux triangles, le fragment shader fait tout le taf.

Bref j'ai du mal à comprendre cette volonté de remplacer l'OS par un navigateur. Bientôt la mode ce sera de développer un navigateur dans le navigateur (Et on l’appellera PoupéesRusses Explorer )

[super_navide]

javascript est ptêt bien le langage le plus lent du monde, c'est connu, faut éviter de faire n'importe quoi avec

webgl est justement plutôt bien fichu pour que tu n'aies pas à te soucier des problèmes de synchronisation entre les cartes (c'est au moins le minimum qu'on est sensé en attendre), il gère toute l'allocation vram tout seul (d'ailleurs ça m'énerve car je comprends rien à ce qui se passe là dessous, apparemment par exemple il ne fait aucune distinction entre buffer statique et dynamique, ni de distinction entre stream et reallocation, et je trouve pas ça propre du tout car du coup je vois pas comment optimiser quelque chose là dedans)
ce qu'l faut connaître surtout c'est les règles d'optimisation, pas de model high-poly, limitation des drawcall, adapter la résolution aux performances des browsers



voilà le genre de démos qui chez moi sont fluides sur chrome uniquement (sur ff et ie c'est la cata, et sur mobile ça doit etre bien pourri aussi...):

http://threejs.org/examples/#webgl_geometry_minecraft
http://threejs.org/examples/#webgl_g...y_minecraft_ao
http://threejs.org/examples/#webgl_geometry_hierarchy2
http://threejs.org/examples/#webgl_geometry_shapes
http://threejs.org/examples/#webgl_i...ing_pointcloud
http://threejs.org/examples/#webgl_i...e_voxelpainter
http://threejs.org/examples/#webgl_lights_hemisphere
http://threejs.org/examples/#webgl_lights_pointlights
http://threejs.org/examples/#webgl_l...llada_keyframe
http://threejs.org/examples/#webgl_l...llada_skinning
http://threejs.org/examples/#webgl_loader_json_blender
http://threejs.org/examples/#webgl_l...n_objconverter
http://threejs.org/examples/#webgl_shader

avec de la 3d simple on s'en sort quoi.

pour du web j'estime que c'est amplement suffisant. ça fait des jolis bidules pour décorer les sites et on recherche pas à faire grand chose de plus vu qu'à vrai dire on a pas trop le temps. quand t'as deux semaines pour peinturlurer un template wordpress, la bande effect html5 c'est en option si il te reste du temps, sinon on vit bien sans

et ceux qui sont pas contents parce qu'ils veulent imiter leur ps4, il va falloir se faire une raison, s'il y'a pas de place pour vous chez ubisoft c'est qu'il y'a pas de place

Moi les démos tourne tres bien sur chrome a 60 FPS sur mon portable donc pour ceux qui disent que WebGL c nulle ca rame etc ....
Changé de PC

[TiranusKBX]

Bref j'ai du mal à comprendre cette volonté de remplacer l'OS par un navigateur. Bientôt la mode ce sera de développer un navigateur dans le navigateur (Et on l’appellera PoupéesRusses Explorer )

et pourquoi pas "Gigogne Explorer" ?

[p3ga5e]

C'est un bon exemple d'utilisation du webgl.

Quand à la question des performances c'est les développeurs qui en sont responsables, il faut déterrer les vieilles techniques d'optimisation et être copain avec le taskmgr.
Revenir à de la 3d simple je vais pas m'en plaindre, ça fait moins de boulot...

Heu c’est quoi la 3D simple ? Revenir plus de 20 ans en arrière et coder un moteur de raycasting avec le context 2D ?
En plus d’être moche, je ne suis même pas sure que cela soit performant, les vielle techniques de rendu ne sont pas forcément adapté aux technos et hardware actuel !

Alors qu’en est- il des vielles techniques d’optime C/C++, A l’époque ou je travaillé sur console PS1, GameCube et Dreamcast, je me souviens que :

• L’on désactivé le RunTimeTypeInfo RTTI du compilateur ;
• L’on désactivé la gestion d’exception du compilateur ;
• L’on allouer de la mémoire uniquement sur la pile ;

Arf 3 axes d’optims impossible en javascript!

Un développeur C/C++, ne connaissant pas trop javascript utilisera un Array en pensant que les données seront plus rapides en random access, c’est une erreur car l’objet Array a pour protoype le type Object et que c’est ce dernier qui dispose d’une méthode en random access, vertex[i] sera plus lent si vertex est une instance de Array plutôt qu’une instance d’Object .

De manière plus général la POO en JavaScript sera plus couteuse qu’en C++, Les développeurs C++ optimise leurs codes en utilisant judicieusement la directive inline cela leurs permet, au niveau code, d’utiliser la spécialisation et le polymorphisme sans que cela impacte les perfs au runtime ! Là encore c’est un axe d’optim impossible en javascript.

On pourrait croire que les techniques d’optims au niveau code, du genre frustum culling, soit tous aussi vallable en C/C++ qu’en Javascript ! et ben pas forcement ! tester si un OBB , un AABB ou même une BS se trouve dans le champs de la camera peut être plus couteux que de simplement lancer la rastérisation de l’objet sans se soucier de savoir si il est dans le champ !
Pourquoi cela ? Car tous ces vielles bidouilles d’optims ont un impact insignifiant face à la puissance de la parallélisassions des calculs, qu’apporte WebGL !

Vive les instructions SIMD ! Vive le GPU !

[xavierbourry]

WebGL est la spécification d'une bibliothèque graphique 3D au même niveau que OpenGL ou Direct3D. Celle-ci repose sur OpenGL ES 2.0 (la spécification pour l'embarqué de OpenGL) et permet de créer des pages Internet intégrant du contenu 3D. Ainsi, à l'aide de HTML 5 et du Javascript vous pouvez afficher un rendu accéléré par la carte graphique et bénéficiant donc de la puissance du GPU.

WebGL n'est pas une bibliothèque graphique 3D. La bibliothèque 3D utilisée par WebGL est OpenGL ES2.0, et parfois les appels vers cette bibliothèques sont transcrits en DirectX via Angle, notamment sous Windows. WebGL est un binding, soit une liaison entre Javascript et OpenGL ES2. Il permet simplement d'utiliser OpenGL ES via javascript.

WebGL permet d'aller bien plus loin qu'afficher du contenu 3D sur des pages internet. En effet depuis le VRML de l'eau a coulé sous les ponts. WebGL permet de créer des applications interactives 3D dans le navigateur : des jeux, des configurateurs 3D, des interfaces de navigation, de la réalité augmentée, ...

A l'aide d'HTML5 et de javascript il est effectivement possible d'afficher du rendu accéléré par la carte graphique : sur un navigateur moderne tout est accéléré par le GPU. Mais WebGL ne fait pas partie du standard HTML5. HTML5 est un standard normalisé par le W3C, consortium industriel spécialisé dans le web, tandis que WebGL est spécifié par le Khronos Group, consortium industriel spécialisé dans l'accélération matérielle, et pas moins légitime que le précédent (même si son nom est moins hype et fait moins branché que le World Wide Web Consortium).



Le support

Actuellement, les principaux navigateurs présents sur le marché disposent du support de WebGL :

Firefox (6 juillet 2010)
Google Chrome(3 février 2011)
Safari (20 juillet 2011)
Opera (14 juin 2012)
Internet Explorer (17 octobre 2013).
les versions mobiles de Firefox, Opera et du navigateur de Blackberry supportent également WebGL.

L'information est plutôt approximative. Pour des statistiques détaillées des support il vaut mieux se fier à caniuse.com/webgl. Il est nécessaire de préciser que bien que Safari ai implémenté WebGL précocement, il a fallu attendre la version 8 du navigateur pour que WebGL soit activé par défaut (sortie après IE11 dont l'activation est par défaut). WebGL sera également compatible avec la version 8 d'iOS Safari, et il l'est déjà avec les dernières moutures d'IE mobile.



La sécurité

On notera aussi le possible second frein lorsque des failles de sécurité critiques ont été découvertes dans le standard même, entraînant notamment la vive réaction de la communauté et de Microsoft.

Lors des débuts de WebGL, Microsoft tentait d'imposer sa technologie propriétaire, Silverlight, d'où sa réticence face à WebGL. Depuis Internet Explorer a rapidement comblé son retard, implémenté WebGL depuis la version 11 et Microsoft soutient également le développement du moteur BabylonJS. Deux failles de sécurité ont été découvertes dans la foulée de la sortie de Firefox 4 avec WebGL activé par défaut, et ont été très rapidement corrigées. L'une permettait de récupérer des images normalement accessibles via un login (on peut voler des photos de Facebook waouuh !), et l'autre permettait de récupérer des contenus des tampons vidéos, pour certains GPU avec des pilotes non sécurisés.

Actuellement, WebGL est désactivé (du moins avec Chrome) si les pilotes GPU ne présentent pas les impératifs de sécurité nécessaires (même s'ils seraient en mesure de faire tourner WebGL). Les seuls failles restantes permettent de faire planter certains navigateurs, comme on pourrait le faire en javascript/action script en jouant sur les boucles infinies et la saturation mémoire.



Le mouton noir du Khronos Group ?

Il ne faut pas non plus oublier que l'accélération graphique dans WebGL est disponible uniquement que si la carte graphique implémente correctement la spécification. Cela a aussi provoqué une certaine lenteur dans l'évolution du support d'OpenGL, notamment sous Linux où il était peu présent. Maintenant, nous pouvons dire que ces soucis sont globalement résolus.

Nous ne l'oublions pas. Les fabricants de cartes graphiques sont présents dans le Khronos Group (ATI, NVIDIA, AMD). WebGL nécessite pour eux de produire des drivers présentant des meilleurs impératifs de sécurité. Il s'agit d'un progrès. Depuis 2 ans n'importe que ordinateur, même le plus bas de gamme, est compatible WebGL sans avoir à réaliser de quelconque manipulation (changement de pilote, de paramètres du navigateur).

C'est totalement gratuit d'affirmer que WebGL a ralenti l'évolution d'OpenGL. OpenGL continue d'avancer, indépendamment de WebGL. OpenGL ES également. WebGL est basé sur OpenGL ES2, et OpenGL ES 3 est sorti. OpenGL est à la pointe, approximativement OpenGL ES suit OpenGL avec une dizaine d'années de retard, et WebGL suit OpenGL ES avec 2 ans de retard.

Sous Linux les problèmes proviennent souvent des fabricants de cartes graphiques qui livrent des pilotes peu aboutis pour ce système d'exploitation. Avec Nvidia il n'y a pas de problème, mais avec ATI l'installation des pilotes est parfois plus difficile.



WebGL a un avenir radieux !

Après un paragraphe louant le WebGL, l'auteur émets quelques objections :

WebGL a toutefois quelques limitations :

absence de tampon de sélection ;
absence de textures 3D ;
absence de geometry shader.

Ces trois fonctionnalités ne sont pas présentes dans OpenGL ES2.0 . Il est donc impossible qu'elles soient présentes dans WebGL. Le tampon de sélection peut tout de même être émulé pour faire du picking cheap.


L'auteur semble s'être abondamment inspiré de l'article Wikipédia sur WebGL. Les défauts reprochés sont les mêmes, et les petites imprécisions quant à sa compatibilité aussi.

Finalement, il n'y a toujours pas d'application phare pour cette technologie. De plus, pour les jeux vidéo et les applications intensives le JavaScript et la surcouche apportée par le navigateur peut être aussi un facteur décisif et ainsi empêcher l'adoption de ce standard.

WebGL commence tout juste à avoir un taux de compatibilité sur desktop permettant d'envisager des applications commerciales (66% d'après http://caniuse.com/#feat=webgl ). Peu de développeurs sont actuellement formés à cette technologie, et les projets importants nécessitent encore du temps. Les décideurs sont souvent peu au courant de ce que permet cette technologie.

Les jeux vidéos et les applications intensives resteront évidemment natives. COD ou Solidworks ne passeront jamais dans le navigateur. Les joueurs et les ingénieurs CAO ont des machines puissantes, sont prêts à acheter les licences, à télécharger le produit. Ils recherchent la performance avant tout.

WebGL est uniquement un binding, et ne joue pas sur le même tableau que Unity qui propose un workflow de création 3D remarquable, et depuis peu il est possible d'exporter des applications Unity en WebGL. WebGL ne sera pas non plus aussi optimisé et contiendra moins de fonctionnalités que des technologies propriétaires et tournant sur un nombre limité de plateformes comme Metal.

Le Khronos Group est notamment constitué de développeurs de navigateurs : Google, la Fondation Mozilla, Opera, ..., de concepteur de système d'exploitation: Apple, Canonical, ... de fabricants de matériel : AMD, Nvidia, ... et d'Universités parmi les plus reconnues. C'est compliqué et cela prend du temps de mettre tout le monde d'accord sur un standard. Et même si au final ce dernier à des défauts, sa portabilité est imbattable.



WebGL sera intéressant, voire incontournable pour :

• le casual gaming,
• les configurateurs produit,
• les interfaces de navigation 3D (avec la prise en compte des NUI notamment),
• de nouvelles expériences Web (ex : http://www.chromeexperiments.com/det...ti-general/?f= ),
• la recherche en algo 3D et les simulations (WebGL permet de partager le code très simplement, sans nécessiter d'OS/de librairie particuler ),
• des applications dont on n'a pas encore l'idée !

En bref, c'est un grand OUI, WebGL a un avenir !

[SylvainPV]

Je ne sais pas si WebGL a un (long) avenir, je ne suis pas devin. Ce dont je suis sûr, c'est que les progrès faits sur cette techno en l'espace de quelques années sont énormes. Je me rappelle des premiers builds de three.js: on était déjà tout fous en voyant un drapeau à la texture moche flotter. Que dire maintenant quand on voit des démos splendides, des jeux complets et même le portage de l'Unreal Engine 3, à part WAOUH ! Je sais bien que Flash, Unity et d'autres technos en sont à ce niveau depuis des années. Mais WebGL est un standard, utilisable peu importe la plate-forme, et accessible par un simple clic sur un lien: je pense qu'il y a de quoi être enthousiaste.

J'ai travaillé personnellement sur plusieurs jeux HTML5 (dont le dernier, Opus Magnum, lors du Game Dev Weekend Developpez.com), je suis donc bien placé pour voir tous ces progrès autant sur la techno que sur l'outillage. Ce que je trouve génial, c'est de bosser sur un jeu "PC" et de se dire quelques temps plus tard: "Tiens, si j'essayais sur mon téléphone ?". Je ne dis pas que c'est parfait, ça ne l'est jamais si on y a pas porté d'effort particulier. Mais très souvent, ça tourne, et parfois même ça tourne très bien ! Et tout ce qu'on a fait c'est de hit une simple URL. Je trouve ça génial.

[Nicam]

Un peu d'ouverture d'esprit ne fait pas de mal Musclor.
Les jeux videos sur navigateur sont une réalité, que tu le veuille ou non !
Des boites ont vu le jour avec ce procédé, ils tentent de gagner de l'argent, et n'ont pas spécialement le besoin, les moyens de refaire tout eux même. La 3D via WebGL, c'est d'avoir une solution standard déployable partout.

Limiter la 3D à certains périmètres est une erreur à mon sens, car nous sommes au début de l'aventure.
La machine moyenne est largement puissante pour satisfaire tout le monde, les mobiles sont de plus en plus puissant en gardant une certaine autonomie. Le jeu en 3d web ne remplacera surement pas le jeu en 3d native, mais c'est un complément, une possibilité, une opportunité. Certes, on est encore très loin d'offrir un Battlefield4 sur browser, mais il faut se rappeler qu'on part de loin. Bien malin celui qui peut prédire ce qui va se passer...

L'argument de dire que c'est un bouffe CPU est une ânerie : un CPU est fait pour tourner, on lui demande juste de tourner en consommant moins, et on est sur la bonne voix. Pourquoi s'exciter ?

Je salue fortement les initiatives de framework, tel que Babylon.js (Imikado, ca me fait rire que tu en parles ici même, car l'équipe qui a accouché de ce framework est une bande de potes bossant chez Microsoft). Je trouve ce dernier franchement impressionnant lorsqu'on garde en tête le contexte. Bravo donc à David Catuhe et autres David Rousset, et Michel Rousseau (wep, des petits Francais pour leur boulot, et accessoirement leur bonne humeur.

Je pense que l'avenir passera par la 3D, y compris sur le web. WebGL n'est qu'une étape.

[Greg-dev]

Pour information la version 5 de Unity supprimera le plugin web player pour le remplacer par ... ?
Du WebGL !

Pour moi le WebGL se limite au lowpoly, après si on utilise NodeJS faut voir ce qu'on en faire

[I_Pnose]

Pour information la version 5 de Unity supprimera le plugin web player pour le remplacer par ... ?
Du WebGL !

Il n'a jamais été question de supprimer le webplayer dans le v5 d'Unity.

"We're coming into a world where some browsers will not support the [Unity] plugin, but some browsers will not support WebGL. Us having both means you can cover every browser."

Sans compter que l'export WebGL serait une option payante...

[Greg Latiner]

Sans compter que l'export WebGL serait une option payante...

C'était ce qui était prévu en effet, mais finalement le deployement webGL sera accessible sans avoir à payer de supplément

[LittleWhite]

Ah, j'ai entendu le contraire. Juste avant la conférence Unity tout dernièrement (Unite) ils ont annoncé qu'il serait gratuit pour tous.

@spacegoo :
J'ai du mal à dire que WebGL n'est qu'un binding. Certes, WebGL expose les fonctionnalités de OpenGL ES 2 et cela, de la même façon (OpenGL ES, afin que ce soit compatible avec les mobiles), mais en réalité, c'est bien la spécification d'une bibliothèque. Souvent, cela repose sur OpenGL ou DirectX, car actuellement, les systèmes ne font pas autrement, mais rien n'oblige que cela soit ainsi.

[I_Pnose]

C'était ce qui était prévu en effet, mais finalement le deployement webGL sera accessible sans avoir à payer de supplément

Ah ben c’est une très bonne chose s’ils sont revenus là-dessus ! (bon par contre j’espère qu’ils n’ont pas non plus retourné leur veste quant à la conservation du plugin actuel ; j’ai rien contre WebGL mais vu les témoignages divergents de ce fil, je préfère avoir une alternative, au cas où).

[daimoc]

Oui clairement webGl à de l'avenir mais pas tout seul. Les portages de unity et de l'unreal Engine ne sont possible avec de performance pottable que grâce à l'arrivé de compilateur C++ vers Javascript tel que emscripten (http://kripken.github.io/mloc_emscri...ppcon.html#/28).
Du coup on garde tout le moteur c++ et le transporte presque automatiquement dans le navigateur en perdant pas trop de perf (mais un peu quand même) . Avec l'arrivé des instructions SIMD directement accessible en JS les perfs vont encore s'améliorer.

Pour preuve les démos en webgl de unity : http://beta.unity3d.com/jonas/DT2/ et http://beta.unity3d.com/jonas/AngryBots/ qui tourne carrément bien même sur une machine de milieu de gamme.

[jean_kevin_musclor]

J'ai testé les portages emscripten et désolé mais ils font perdre énormément en perfs... non seulement parce qu'on se retrouve avec un langage 20 fois plus lent que le c++ mais en plus parce que leur compilation c++ -> assembleur -> javascript complique énormément les calculs et il faut se taper la réecriture en js des parties à optimiser.

Le portage webgl de unreal engine chez moi tout ce qu'il arrive à faire c'est me planter la machine.

Le portage webgl de unity je l'ai à 3 fps environ. même la version flash était dix fois plus rapide.

quand tu vois la quantité de calcul rien que pour gérer une matrice camera tu comprends vite que javascript n'est pas en mesure de faire tourner des trucs comme physx ou du batching dynamique, et encore moins avec le portage super crade de emscripten.

[Astraya]

J'ai testé les portages emscripten et désolé mais ils font perdre énormément en perfs... non seulement parce qu'on se retrouve avec un langage 20 fois plus lent que le c++ mais en plus parce que leur compilation c++ -> assembleur -> javascript complique énormément les calculs et il faut se taper la réecriture en js des parties à optimiser.

Le portage webgl de unreal engine chez moi tout ce qu'il arrive à faire c'est me planter la machine.

Le portage webgl de unity je l'ai à 3 fps environ. même la version flash était dix fois plus rapide.

quand tu vois la quantité de calcul rien que pour gérer une matrice camera tu comprends vite que javascript n'est pas en mesure de faire tourner des trucs comme physx ou du batching dynamique, et encore moins avec le portage super crade de emscripten.

Non mais tu es sérieux là? Tu penses vraiment que des boites comme Epic et Unity qui sont en très fortes concurrence sortiraient des démos à 3fps? Epic citadel tourne en moyenne entre 25 et 30 fps sur une machine bas de gamme. Si tu as des ralentissement alors le problème vient de TA machine, de TES drivers, de TES applications installées, de TES plugins... bref cela vient de TA machine cliente.
La même démo tourne en natif desktop à 48fps sur les mêmes machines, les perfs sur donc tout à fait acceptable pour un jeu dans un canvas HTML5.
Ton oeil voit à peine la différence au dessus de 30fps, après c'est juste une question de fatigue et de confort du regard, peu de moteur desktop peuvent se venter de faire du 60FPS continue sur PC et console. 30FPS ici c'est un très bon boulot.

Ces démos sont des vitrines commerciales! Comment tu peux penser qu'ils ont fait un boulot de m*rde qui tourne à 3 FPS?

De plus tu devrais plus te renseigner sur Emscripten... Tu dis (c++ -> assembleur -> javascript) moi je te dis (c++ -> LLVM -> javascript). Encore une fois, tu crois vraiment que si les technos était pourrit comme tu dis , Epic, Unity et d'autre perdrait leur argent dans le développement de leur moteur sur ces technos?

J'aimerais bien voir tes tests et le code créer pour.