Version imprimable
Ce qui suit ne sont que des hypothèses. A vérifier donc...
Dans la démo avec les boites, seule la partie calculs (moteur physique) a été compilée en asm.js.
La démo du FPS a été entièrement compilée en asm.js (ou en WebAssembly si le navigateur le supporte). Pas seulement le moteur physique, mais aussi la partie rendu graphique, goulet d'étranglement à priori important dans le framerate global, comme le suggère mon utilisation de 30% du CPU sur l'exemple avec les boites.
C'est clairement pas la partie graphique le problème (une fois le draw call fait, il n'y a aucune différence entre webGL et une appli desktop : c'est le driver qui se démerde avec)
1 thread @ 100 % CPU = 25% CPU sur un quad core. C'est limité de ce coté là. (D'ailleurs j'ai une utilisation de ~55/60% CPU avec Chromium : 2 processes @ 25/30%)
1000 draw calls + la physique ça à l'air de suffire à mettre à genoux un CPU.
Voici un autre exemple qui montre que faire un RE2 sur navigateur, ce doit être possible : https://webassembly.github.io/demo/Citation:
Envoyé par Kannagi
Oui c'est possible , et surtout quand webassembly feront partie du standard web.Citation:
Envoyé par yahiko
Car il sera possible d'avoir les perfs du C++.
Après avec javascript j'ai vu des démos impressionnante sur internet avec WebGL.
De toute façon je suis d'accord on peut faire un WOW en javascript html5 webgl.
stopviolence, laisse tomber ce projet de fou, c'est impossible que tu le mènes à son terme.
Fais comme moi, commence par un petit projet (je fais un Tetris3D sur Unreal Engine 4 en mélangeant blueprints et c++). Une fois ton premier projet bien paufiné et mené à son terme tu pourras te lancer dans un nouveau projet un peu plus complexe et ambitieux, et ainsi de suite...
A mettre la barre d'entrée dans la ionosphère tu vas te dégouter assez rapidement
Tu m'as l'air tout confusionné, toi...
Mais encore ?
Ben c'est pas super_navide qui pose la question, à la base.
De plus si tu regardes dans ce même forum, tu verras un des projets de super_navide...
Au temps pour moi, ce post s'adressait à stopviolence l'auteur du topic. J'ai rectifié.
Je ne comprends absolument pas l’intérêt de vouloir s'acharner à faire faire à JS et au navigateur ce genre de travail.
On est encore a des années d'un rendu comparable avec ce qui se fait avec du c++/openGL/directX, alors certes il y a de la marge de progression comme avec les webassembly mais est-ce que ca suffira?
Quand bien même on arriverait à des performances équivalente, c'est quoi au juste l’intérêt? Pour les gros jeux les ressources doivent prendre 99.9% de la taille du jeu, et donc on peut pas vraiment invoquer la faciliter de déploiement.
La portabilité? J'y crois pas une seule seconde, déjà que pour des sites internets c'est pas toujours évident alors pour des problèmes de performance qui peuvent venir de 1000 raisons différentes c'est quasiment impossible.
Bref je comprends pas! Des suggestions de l'utilité de faire du jeux video (du lourd graphiquement j'entends) sur navigateurs?
J'aurais préféré des réponses en plus des pouces rouges, ca n'aide pas beaucoup au schmilblick!
Perso je trouve que l'intérêt se situe justement au niveau de la portabilité (peu importe la plateforme d'éxecution, si elle prends en charge ce que tu veux faire, ça marchera), c'est quand même plus portable que du compilé.Citation:
Envoyé par micka132
Ensuite ça te permet de ne pas avoir d'intrusion dans ton système, pas de fichier à télécharger et installer dans ton ordinateur, il suffit de vider le cache.
Tu peux y accéder de partout où tu as internet sans avoir à installer quelque chose de spécial.
Le but d'un jeu web n'est pas de concurrencer les jeux client lourd, mais de pouvoir rapidement tester un concept ou truc dans le genre. ça serait quand même hyper pratique d'avoir une version web d'eve online par exemple permettant de tester rapidemment le jeu sans avoir à télécharger les 20 giga non?
Pareil pour tout un tas d'autres jeux, je trouve que justement, l'intérêt est de faire des mini-jeux, des POC, des preview, teaser etc ..... Pour que la personne s'interesse au jeu et finisse par l'acheter en étant sur que le jeu lui plait.
Combien de fois j'ai vu des jeu qui avait l'air super simpa, je les ais acheté, mis 2 jours à les télécharger (en ayant supprimer des trucs avant bien sur), pour au final me rendre compte qu'il est pas top. C'est le genre de problème que solutionne le jeu web.
J'allais oublier, la maintenance, maintenir un jeu web, est beaucoup plus simple qu'un client lourd ne serait-ce qu'au niveau du déploiement des mise à jour, un seul endroit qui se propage à tout les joueurs.
Peut-on s'arreter au fait que ca "marchera". Si les performances sont inégales entre navigateur ca peut poser des problèmes. C'est juste impossible d'avoir les même performance même sur le même navigateur mais sur un autre OS.Citation:
Envoyé par skeud
Effectivement on peut imaginer un mode "dégradé", mais ce mode sera quasiment aussi compliqué à faire que le jeu classique, et donc je ne suis pas bien certains que les éditeurs soient trop d'accord.Citation:
Envoyé par skeud
Avant il y avait les démos légère, ca existe toujours, mais maintenant elle sont énormes> Pourquoi?Parceque comme je le disais ce sont les ressources(médias) qui sont ultra volumineux. Soit sur la partie web tu te retrouves avec du low poly, soit tu mettras autant de temps a télécharger la première scène/carte.Citation:
Envoyé par skeud
Je ne vois pas bien la différence entre un client et un navigateur qui se connecte à une url qui va lui retourner la liste de tout ce qu'il y a à charger. Dans les deux cas l'éditeur ne fait que mettre sur cette url les modifications en question.Citation:
Envoyé par skeud
En fait ta supposition est vrai seulement si l'on fait un parallèle avec les applis de gestion en entreprise. La plupart des clients lourds n'intègrent effectivement pas de mise à jours automatiques et le passage par le web est beaucoup plus simple. Ce n'est pas le cas pour les JV, ca fait longtemps que les clients se mettent à jour seuls.
Tu peux penser qu'on peut quand même s’épargner la création/maintenance de ce client, ce que je ne pense pas, parce qu’on est à des années lumières d'une page web et le jeu doit être conçu afin d'aller chercher les ressources au bon moment=>donc on est plus dans du simple http, il va falloir ordonnancer tout ça et ça ne sera pas magique.
J'entends tes arguments, et ils ne sont pas mauvais effectivement. Je pense que finalement, la différence web/client lourd dépend vraiment de l'affinité que l'on a des techno et le but que l'on souhaites atteindre.
Il y a des avantage d'avoir un client léger pour un jeu de la même manière qu'il y a des avantage d'avoir un client lourd, tout dépends de l'utilisation finale et du but recherché. :).
Bonjour,
Tout d'abord je m'excuse de m'être planté à propos du rpg facebook, j'avais pas fait clic-droit et en effet c'est du flash donc pas du html5.
Ensuite je réponds globalement aux autres, les expérimentations futuristes sur les browsers c'est intéressant mais ça va pas être standard dans l'immédiat, là pour l'instant je m'intéresse à ce qui fonctionne maintenant, et sachant que y'a encore plein de browsers mobile où le webgl marche pas il est clair que pour l'instant ce genre de projet va rester dans les cartons.
Et réponse perso pour Guitz >
On devrait échanger nos idées, toi tu fais un rpg avec unreal, moi je fais un tetris avec html5, ça serait plus cohérent que l'inverse ^^