Trabalhadores da Web para simulação de física de jogos em HTML5?

12

Um pouco relacionado a esta questão .

A idéia é garantir o mesmo comportamento físico, tanto quanto possível. Seria possível executar física de etapas de tempo fixo em um trabalhador da Web? A interface do usuário se atualizaria com uma taxa de atualização diferente / variável.

Alguém já tentou isso ainda?

physics javascript html5

— Petteri Hietavirta
fonte

O que você pretende ganhar usando um trabalhador da Web? Até agora, minha resposta seria: isso funcionará, mas por que se preocupar?

— aaaaaaaaaaaa 25/10

3

Eu encontrei esse experimento . Ele executa a física Box2d em um trabalhador da Web. Ainda não verifiquei detalhadamente como ele contorna os problemas mencionados nos comentários de Vincent Scheib.

— Petteri Hietavirta
fonte

Boa experiência. Também tenho acompanhado esses tipos de projetos. Infelizmente, a maioria ainda está vinculada ao Java / C. Eu acredito que o OP está procurando uma maneira de fazer isso nativamente no navegador (sem plugins).

— Kevin Peno

2

Artigo sobre o mesmo por um cara do google: t.co/AuhPptB

— sorenbs

2

Isso pode funcionar, por mais que WebWorkersiga o padrão de observador , a document(página html do proprietário) só pode ouvir e postar mensagens para / de um trabalhador. A partir disso, existem algumas opções, eu acho. Em todos os casos, acho que você precisará encontrar uma maneira de determinar o FPS ideal do agente do usuário para otimizar as informações. Então você pode:

Diga aos trabalhadores para postar mensagens nesses intervalos de tempo
- Desvantagem (ões): você deve assumir que o documentitem estará pronto para a resposta quando isso acontecer.
Diga ao documentpara enviar uma mensagem ao trabalhador solicitando física no intervalo de tempo x; então, o trabalhador publicaria uma resposta (espero) logo após isso.
- Desvantagem (ões): como todas as postagens e respostas são assíncronas, pode haver atrasos entre a solicitação e a resposta do trabalhador. Nesse caso, você também precisaria anular o onmessageevento para impedir que você documentouça quando não espera.

Tenho certeza de que há outras coisas que eu perdi ou maneiras de lidar com as comunicações também. Estou ansioso por outras respostas sobre o assunto!

— Kevin Peno
fonte

1

a) Cuidado com o desempenho! Considere requestAnimationFrame e sinalizar um 'manter viva' para o seu trabalho a partir dele, para que você não queimar CPU se o guia é colocado em segundo plano (talvez por muito tempo)

— Vincent Scheib

b) IIRC Todas as mensagens do trabalhador serão recebidas no thread principal, elas serão colocadas na fila. Pense no impacto que isso terá no seu thread principal, se você tiver cinco atualizações, mas precisar apenas das mais recentes. Você também não pode dizer que tem mais por vir.

— Vincent Scheib

c) Todas as mensagens estão fazendo cópias de dados. Quanto mais dados você tiver que enviar entre os encadeamentos, maior será o trabalho de cópia e coleta de lixo. Portanto, uma vitória aqui só existirá se houver uma alta taxa de dados de computação / mensagem.

— Vincent Scheib

@Vincent, no que diz respeito a B), é por isso que eu disse que você documentsempre deveria estar pronto para encontrar um fps razoável ou seguir a opção 2, em que o trabalhador não faz nada até documentpedir.

— Kevin Peno

2

Physijs usa um trabalhador da web. Ele cola a munição física com os objetos Three.js e os atualiza conforme necessário. Possui etapas de tempo fixo e fluido, acredito

— ebaum
fonte