Travailleurs Web pour simulation de physique de jeu HTML5?

12

Un peu lié à cette question .

L'idée est de garantir autant que possible le même comportement physique. Serait-il possible d'exécuter une physique de pas de temps fixe sur un travailleur Web? L'interface utilisateur se mettrait à jour avec un taux de rafraîchissement différent / variable.

Quelqu'un a-t-il déjà essayé cela?

physics javascript html5

— Petteri Hietavirta
source

Que pensez-vous gagner en utilisant un travailleur Web? Jusqu'à présent, ma réponse serait, cela fonctionnera, mais pourquoi s'embêter?

— aaaaaaaaaaaa

3

J'ai trouvé cette expérience . Il exécute la physique de Box2d sur un travailleur Web. Je n'ai pas encore vérifié dans le détail comment il contourne les problèmes mentionnés dans les commentaires de Vincent Scheib.

— Petteri Hietavirta
source

Bonne expérience. J'ai également suivi ces types de projets. Malheureusement, la plupart sont encore liés à Java / C. Je crois que OP cherche un moyen de retirer cela nativement dans le navigateur (pas de plugins).

— Kevin Peno

2

Article sur le même sujet par un gars de Google: t.co/AuhPptB

— sorenbs

2

Cela pourrait fonctionner, mais WebWorkersuivez le modèle d'observateur , la document(page html qui appartient au travailleur) ne peut qu'écouter et publier des messages vers / depuis un travailleur. De cela, il y a quelques options, je suppose. Dans tous les cas, je pense que vous devrez trouver un moyen de déterminer le FPS optimal de l'agent utilisateur afin d'optimiser les informations. Vous pouvez alors:

Dites aux travailleurs de publier des messages à ces intervalles de temps
- Inconvénient (s?): Vous devez supposer que le documentsera prêt pour la réponse lorsqu'elle se produira.
Dites au documentd'envoyer un message au travailleur demandant de la physique à un intervalle de temps x, puis le travailleur posterait une réponse (espérons-le) peu de temps après.
- Inconvénient (s?): Étant donné que tous les messages et réponses sont asynchrones, il peut y avoir des délais entre la demande et la réponse du travailleur. Dans ce cas, vous devrez également annuler l' onmessageévénement pour vous empêcher documentd'écouter lorsqu'il ne devrait pas l'être.

Je suis sûr qu'il y a d'autres choses que j'ai manquées ou des moyens de gérer les communications également. J'attends avec impatience d'autres réponses sur le sujet moi-même!

— Kevin Peno
source

1

a) Attention aux performances! Considérez requestAnimationFrame et signalez un `` garder en vie '' à votre travailleur, afin de ne pas graver de CPU si l'onglet est placé en arrière-plan (peut-être trop longtemps)

— Vincent Scheib

b) IIRC Tous les messages du travailleur seront reçus sur le thread principal, ils feront la queue. Pensez à l'impact que cela aura sur votre thread principal, si vous avez 5 mises à jour mais que vous n'avez besoin que des dernières. Vous ne pouvez pas non plus dire que vous avez plus à venir.

— Vincent Scheib

c) Tous les messages font des copies de données. Plus vous devez envoyer de données entre les threads, plus le travail de copie de données et de récupération de place est important. Ainsi, une victoire ici n'existera que s'il existe un rapport élevé de données de calcul / message.

— Vincent Scheib

@ Vincent, en ce qui concerne B), c'est pourquoi j'ai dit que vous auriez besoin d'être documenttoujours prêt en trouvant un fps raisonnable ou d'opter pour l'option 2 où le travailleur ne fait rien jusqu'à ce qu'il le documentdemande.

— Kevin Peno

2

Physijs utilise un travailleur Web. Il colle la physique des munitions avec les objets Three.js et les met à jour au besoin. Il comporte des pas de temps fixes et fluides, je crois

— ebaum
source