Веб-працівники для моделювання фізики ігор HTML5?


12

Трохи пов'язане з цим питанням .

Ідея полягає в тому, щоб максимально гарантувати ту саму фізичну поведінку. Чи можна було б виконати фізику з фіксованим часовим кроком на веб-працівнику? Інтерфейс користувача оновив би себе різною / змінною частотою оновлення.

Хтось ще пробував таке?


Що ви гадаєте отримати, користуючись веб-працівником? Поки моя відповідь буде, це спрацює, але навіщо турбуватись?
— aaaaaaaaaaaa

Відповіді:


3

Я знайшов цей експеримент . Він працює з фізикою Box2d на веб-працівнику. Я ще не докладно перевіряв, як це стосується проблем, згаданих у коментарях Вінцента Шейба.


Хороший експеримент. Я також слідкував за такими проектами. На жаль, більшість все ще пов'язана з Java / C. Я вважаю, що ОП шукає спосіб вирішити це в самому браузері (без плагінів).
— Кевін Пено

2
Стаття про те саме від google guy: t.co/AuhPptB
— sorenbs

2

Це може спрацювати, однак WebWorker, якщо слідувати шаблону спостерігачів , document(html-сторінка, яка належить працівникові), може слухати та розміщувати повідомлення працівника та / лише їх повідомлення. З цього, мабуть, є кілька варіантів. У всіх випадках, я думаю, вам потрібно буде знайти якийсь спосіб, щоб визначити оптимальний FPS користувача-агента, щоб оптимізувати інформацію. Тоді ви могли:

  • Розкажіть працівникам розміщувати повідомлення в ці часові інтервали
    • Нижче (і?): Ви повинні припустити, що documentволя буде готова до відповіді, коли це станеться.
  • Скажіть, documentщоб надіслати повідомлення працівнику, що вимагає фізики, через проміжок часу x, тоді працівник опублікує відповідь (сподіваємось) незабаром після цього.
    • Нижня частина (ів?): Оскільки всі повідомлення та відповіді асинхронні, може виникати затримка між запитом та відповіддю від працівника. У цьому випадку вам також доведеться звести нанівець onmessageподію, щоб запобігти її documentпрослуховуванню, коли цього не очікується.

Я впевнений, що є інші речі, які я пропустив, а також способи поводження з комунікаціями. Я буду з нетерпінням чекати інших відповідей на цю тему!


1
а) обережність щодо продуктивності! Розгляньте requestAnimationFrame і надішліть на нього своєму працівникові «збережіть життя», щоб ви не спалювали процесор, якщо вкладка розміщена у фоновому режимі (можливо, занадто довго)
— Vincent Scheib,

b) IIRC Усі повідомлення від працівника будуть надходити в основний потік, вони будуть в черзі. Подумайте, який вплив буде мати ваша основна тема, якщо ви отримали 5 оновлень, але потрібні лише останні. Ви також не можете сказати, що вас чекає більше.
— Вінсент Шейб

в) Усі повідомлення роблять копії даних. Чим більше даних вам доведеться надіслати між потоками, тим більше буде копіювання даних та збирання сміття. Отже, виграш тут буде лише у випадку високого співвідношення даних обчислень / повідомлень.
— Вінсент Шейб

@ Вінсент, щодо Б), тому я сказав, що вам потрібно буде documentзавжди бути готовим, знайшовши розумний кадр в секунду, або піти з варіантом 2, коли робітник нічого не робить, поки цього не documentпопросить.
— Кевін Пено

2

Physijs використовує веб-працівника. Він склеює фізику боєприпасів з об'єктами Three.js та оновлює їх, як потрібно. Я вважаю, що це фіксований та рідинний етапи часу

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.