Объединение возможностей Processing.js и веб-работников

Question

Я немного почитал о двух (относительно) новых концепциях в языке Javascript - Web Workers и awesome Джона Ресига Processing.js (ну, не совсем новая "концепция Javascript", но вы поняли мою идею).В Интернете есть несколько замечательных примеров того и другого, но мне еще предстоит найти тот, в котором эффективно используются оба метода.По-моему, это выглядит довольно интересно и мощно, так что я подумал, что мне лучше просто попробовать.

Однако я действительно не могу придумать наилучший дизайн скрипта для интеграции этих двух...Мне кажется, что обычно, когда используется Processing.js, определяются некоторые классы внутри "обработка-приложение".Это позволяет вам использовать Java-подобный синтаксис для достижения этой цели.Однако эти классы доступны только в рамках приложения-обработки, что очевидно.Но тогда у нас есть Рабочие...В это удивительный пример: объект функции Javascript сначала определяется в отдельном скрипте, и если требуется рабочее использование, Рабочий скрипт импортирует прототип этого объекта и как бы "прикручивает" себя к нему.

Мне эти два понятия не кажутся "взаимозаменяемыми", поскольку вы не можете получить доступ к классу, который вы определили в приложении-обработке, когда находитесь в своем рабочем скрипте.Вероятно, по какой-то причине, поскольку классы, подобные обработке, определенно не очень похожи на Javascript.Насколько я могу видеть, мне придется создать аналогичное определение класса (в виде прототипа новой функции) в моем рабочем скрипте - что не очень хорошо с точки зрения ремонтопригодности и просто кажется мне ужасно плохим дизайном, хотя я все еще большой новичок в этом вопросе.

Я что-то упускаю из виду?Хочу ли я чего-то, чего просто не должно быть?Или я просто неправильно понял некоторые фундаментальные понятия?

Спасибо за помощь!

Редактировать:

Продолжал пытаться возиться с прототипом Worker, чтобы "придатьему форму" объекта, для которого он должен выполнять работу, но довольно скоро понял, что это не тот путь.

Давайте попробуем составить схему для работы:У меня есть класс 'Ball', который в значительной степени ничего не делает, кроме хранения двумерной позиции.На каждом draw() цикл, Processing.js называет свою update() метод, который заставляет Мяч принять новое положение.После этого, в display() вызывается метод, при котором Шарик рисует небольшой круг в своем текущем положении.

Для начала ничего сложного.Теперь предположим, что определение нового местоположения шара является довольно дорогостоящей операцией - например, если она включает в себя перемещение шара через "сложное" гравитационное поле.Если этот расчет придется выполнять каждый раз перед рисованием, это вызовет по крайней мере некоторую задержку.Однако, если бы вам удалось выполнить все это одновременно, это могло бы работать более плавно.Итак, я понял, что мог бы предоставить классу Ball дополнительный массив 'positions' в его списке свойств, который будет содержать все его последовательные местоположения.Когда экземпляр Шара создается, он создает нового Рабочего, который начнет вычислять позиции, и каждый раз, когда он завершает одну из них, он отправляет обратно Шару сообщение, содержащее новую двумерную позицию.Затем Шарик поместит эту запись в свой массив positions, поэтому каждый раз, когда ему нужно обновлять свою позицию, он просто переходит к следующей записи в массиве.

В целом - хорошая или плохая идея?Если хорошо, есть какие-нибудь предложения о том, как это спроектировать?

Answer 1

Симы физики 3D-игр (например, на xbox360) обычно запускаются с фиксированной частотой, не зависящей от частоты кадров.Это потому, что физика слишком сложна для аналитического моделирования, поэтому вы выполняете числовые аппроксимации, поэтому вам нужно синхронизировать ошибки детерминированно.Дополнительным преимуществом является то, что частота кадров не связана с физической производительностью, так что вы можете обновлять свою физику на частоте 5 Гц, интерполировать и т.д.

Итак, модель, которую вы описываете, - это именно то, как это делают профессионалы.

Answer 2

вы не можете получить доступ к классу, который вы определили в Processing-application, когда вы находитесь в своем рабочем скрипте.Вероятно , по какой - то причине

Это делается для предотвращения ошибок из-за того, что несколько сотрудников одновременно изменяют одни и те же общие данные.В сообщениях данные копируются, и каждый Работник получает свою собственную копию, так что ему не нужно беспокоиться о том, что одновременная запись приведет к ошибкам.Это простой способ избежать ошибок параллелизма, который обрабатывает их без того, чтобы программисту приходилось беспокоиться об этом (без семафоров или синхронизации и т. Д.).

Answer 3

В этом примере расчет позиций должен быть завершен до розыгрыша мяча - значит, асинхронная обработка не имеет смысла?

p5 сам по себе очень синхронен - есть один центральный нарисуйте метод, который выполняет весь рисунок.

Кроме того, веб-работники не могут получить доступ к dom, поэтому их нельзя использовать для рисования.

Для более сложного приложения, основанного на событиях, такого как игра, могут быть использованы веб-работники.

Answer 4

Просто мысль ... но в обработка сигналов что вы делаете, так это создаете частоту дискретизации, которая преобразует аналоговый сигнал в цифровую информацию.Главное - сохранить ровно столько сигнала, чтобы воссоздать оригинал.Например, то, как MP3-файлы копируются из музыкальных файлов с использованием 128, 192 и т.д.

Итак, если вы перемещаете мяч математически определяемым способом (т.е.вдоль параболы), вы должны быть в состоянии преобразовать траекторию в набор координат, который аппроксимирует аналоговую траекторию.Эти координаты было бы вычислить намного быстрее, чем полный путь.Он также был бы настраиваемым (путем изменения частоты дискретизации).

Я знаю, что это не отвечает ни на один из ваших вопросов о Processing.js или Web Workers.Просто идея, которая поможет вам выполнить эти вычисления более эффективно.

Answer 5

Эта идея напоминает мне идею очереди задач Google, интегрированную в Google App Engine.

http://code.google.com/appengine/docs/python/taskqueue/

Это могло бы вам помочь.

Для моей онлайн-настольной игры asynch я собираюсь внедрить систему, в которой хранится история сообщений, чтобы игроки могли видеть, что происходило, когда была не их очередь.Каждая вещь, которая происходит, получает уникальный идентификатор, и всякий раз, когда игроку отправляются какие-либо сообщения, он отслеживает последнее, которое он получил.Затем, когда они вернутся, они смогут увидеть быструю анимацию всего, что произошло с момента последнего полученного ими сообщения.

И если я дойду до того, что мне понадобится, чтобы сервер что-то обработал, пока клиент не ждет, я использую очередь задач