Аппетит событий и DI

[xdoom]

Лет много назад прочитал и запомнил что-то вроде.
Вы уже знаете, что факт события сопровождается рассылкой сообщений всем его листенерам. Это не слишком сильно сказывается на скорости проигрывания фильма, если листенеров немного. Но если число клипов достигает нескольких сотен, то работа плейера практически останавливается, И значительный вклад в общую нагрузку на систему вносит необходимость информировать все клипы и кнопки более чем о двух десятках видов событий. Естественно, что если рассылать сообщение обо всех событиях всем объектам, то Fash-плейер со средним фильмом не потянет даже новейший Pentium 4.

Вопрос не про спрайты и визуальные объекты, как правильно работать с ними довольно известно.

Вопрос в некотором смысле про mvc, когда создаются классы событий, и все связи работают через слушателей и команды. Особенно когда события передают данные, например каждые 50ms увесистую стопку json, существенно ли это отягощает cpu и ram??? в сравнении с прямой связью между классами.

В проекте используется robolegs - всё супер и клёво, но всё только начинается и пока на мобилке приложение без графики занимает 7метров, и летает, но функционал будет нарастать и если строго следовать правилам mvc, то количество слушателей в легкую перевалит за сотню, а мобилный проц всёж думаю ещё послабей четвёртого пня будет.

по сути, это дублирование вопроса заданного на недавно на потрошителе (http://flash-ripper.com/question-on-mobile-adobe-air-frameworks)

и dependency injection, по идее не много где его использую, но всё же хочу успокоится, что нет у него тех проблем с понижением производительности что были с биндингом во флексе.

[alatar]

Какой смысл гонять каждые 50ms увесистую стопку json? Тем более json.

Добавлено через 4 минуты
Вы это (https://github.com/robotlegs/robotlegs-framework/wiki/Best-Practices#wiki-accessingmodelsandservicesfrommediators) читали?
It is recommended that models and services injected directly into mediators are done so via the interfaces the service and model classes implement. An example of this can be found in the Example Service section below.

[artcraft]

DI не заменяет события
DI это механизм создания зависимостей а не разновидность обсервера

роботлегзовский инжектор, кстати тоже работает не мгновенно из-за вызовов describeType

события можно заменить на signals или на коллбэки

[xdoom]

Какой смысл гонять каждые 50ms увесистую стопку json? Тем более json.
Экшен-игра перемещение игроков, выстрелы. Прощупываю минимальный отклик чтоб было играбельно как quake скажем. Не знаю, но подозреваю там как-то так же сделано. Json в bytearray спрячется по необходимости.
Читал не всё, но над некоторыми кусками медитировал часами, цитируемую строчку пропустил, она вроде значит
injector.mapSingleton(HexEngine); - так не рекомендуется
injector.mapSingletonOf(IPhysModel,SimplePhys) - а так оно самое?

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

А вообще вопрос о скорости выполнении сотен событий в секунду, в разных частях программы.
fps геймплей он такой и физику посчитай и графику нарисуй и с сервера прими и на сервер отправь.
Именно в инициализации самих событий как прокладки между... а не скорости выполнения привязанных к ним метод.

Если оно критично - в топку mvc, используем другой способ.

[alatar]

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

Насчет json. Я так и не понял где вы его применяете. Внутри приложения? Нет смысла. Для передачи данных между игроками и/или сервером? В случае шутера, слишком расточительно. Есть множество более дешевых бинарных форматов, типа AMF. В конце-концов можно свой протокол написать, точно отвечающий нуждам игры и не имеющий ничего лишнего.

Не знаю, но подозреваю там как-то так же сделано
Почтайте о синхронизации состояний в онлайн играх. Например, тут (http://habrahabr.ru/blogs/gdev/135306/) и тут (http://habrahabr.ru/blogs/gdev/123883/).

[xdoom]

Насчет json. Я так и не понял где вы его применяете.
Да, для обмена с сервером, да изменим по необходимости на свой бинарный формат, это не сложно.
Сложно будет изменить архитектуру приложения если окажется что mvc тут далеко не лучшее решение, и мне так кажется всё больше и больше. Тема была создана понять - кажется мне, или это реальность?
Спасибо за статьи, прочитал очень интересно, некоторые мысли автора там тоже догадки, остальное в точности подтвердило мою реализацию Dead Reckoning и 20Hz работы сервера, реализация SimTick интересна но не так отзывчива.

В лес уходим господа )) Вопрос был о производительности событий, и похоже, что они не очень подходят для игр вроде quake. Не говоря уже о mvc паттерне, с которым у меня возникли вопросы о разумном использовании ресурсов cpu и ram.

Вопросы синхронизации, интервала и способа передачи данных между клиентами, немного оффтоп этой темы. Тут о способах и скорости передачи данных между модулями, - этих данных много и часто, задержки в 15-35ms могут быть критичны.

[-De-]

Тормозит не mvc, тормозят события.

[alatar]

События достаточно производительны, если их не слать тысячами (например, летит пуля и сигнализирует "я лечу". это уже маразм).
и этих данных много и часто, и задержки в 15-35ms могут быть критичны.
Статьи я вам привел как раз что бы вы избегали этого "много и часто". Нет в этом необходимости.
тут про передачу данных между модулями, и этих данных много и часто, и задержки в 15-35ms могут быть критичны.
Между какими модулями?
не говоря уже о mvc паттерне с использованием которого у меня возникли вопросы о разумном использовании ресурсов cpu и ram.
Что вы подразумеваете под mvc? Физические движки по-сути контроллеры. Iso объекты в изометрических играх — модели в чистом виде, у которых есть вьюхи (их отображение). MVC как концепция и паттерн отлично ложится на игры, универсальные архитектурные фреймворки нет (если говорить непосредственно о игровом процессе).

[Psycho Tiger]

Есть множество более дешевых бинарных форматов, типа AMF.
В своё время мы паковали обычные Object'ы с динамически созданными полями в AMF и на выходе получалось почти то же самое, что и JSON. В каких случаях это менее расточительно?

[alatar]

Где на выходе?
Менее расточительно по размеру передаваемых данных, менее расточительно при сериализации/десериализации.

[Psycho Tiger]

Ну, я делал дамп того, что генерило AMF. Почти чистый JSON.

[Inet_PC]

Не знаю, толи мы не умеем amf готовить, то-ли, что, но на серверной стороне (php), он у нас жутко тормозил.

[alatar]

AMF я привел в качестве примера бинарного протокола. :)

Ну, я делал дамп того, что генерило AMF. Почти чистый JSON.
Зависит от типа данных.

[xdoom]

Между какими модулями?

20Hz Iservice->Iengine->Iview
и так же в обратном направлении, итого тысяча набирается менее чем за 20сек.
мне тоже кажется это маразмом.

Статьи интересные, там логика а не архитектура, не пуля кричит "лечу", а физ-движок кричит серверу и представлению "свежие пирожкиданные!!!", в то же время сервер кричит движку "покупайтелетят новые пули !!" так вот может получается сотня выкриков каждую секунду. Или нужно иначе?

[alatar]

данные (от сервера или от пользователя) 1 событие (условно) -> движок (расчет нового состояния, изменение модели) 1 событие от модели (данные изменились) (в обратную сторону 1 событие, новое состояние) -> рендер (отрисовка).
Это если гонять состояния. Такой способ крайне неустойчив к взлому.
Другая ситуация.
контроллер (действие пользователя, например "нажали вперед") -> сервер (расчет нового состояния, отсылка клиенту) -> контроллер (изменение внутренней модели) -> рендер (отображение).

Ну и так далее. Где тут сотни событий?

а сервер кричит движку "летят новые пули "!!
По разу на каждую?

Добавлено через 7 минут
P.S. Во многих шутерах вообще нет пуль. Просто мгновенное попадание, а условная пуля (собственно просто отрисовка) летит условно уже постфактум. Т.е. на клиенте пули есть, а на сервере используются, скажем так, лазеры.

[xdoom]

Всё именно так как вы описали, прям один в один, только частота 20Hz чего нить говорит? вся это цепочка в одну сторону и в другую сторону гоняется с периодичностью раз в 50ms. 6-10 событий за 1 итерацию = 50ms посчитайте сколько набёрётся за секунду.

Ну и так далее. Где тут сотни событий?

Понятно где?


По разу на каждую?

на каждое обновления состояния, если ещё к каждому спрайту привязать, то будет вообще феерический капут))

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

p.s. конечно мы не стремимся в сторону battlefild 3 где для пуль есть ещё и гравитация и время жизни, логика quake - отличный старт.
хотя время жизни у наших снарядов тоже есть.

[TanaTiX]

Я бы советовал рассматривать отдельно фреймворки и MVC. Это все же разные понятия.
На счет передачи событий данных через эвенты - может их хранить в моделе уже в распаршенном виде? Не вижу смысла в json.

ЗЫ. Да, опечатался.

[alatar]

6-10 событий за 1 итерацию = 50ms посчитайте сколько набёрётся за секунду.
Какая вам разница сколько их наберется за секунду? Можете еще за год посчитать, получите более впечатляющие цифры. Если обработка не вылазит за эти 50 мс, то тормозов не будет. По памяти тоже должно быть приемлемо. Количество событий за итерацию и время обработки этих событий и есть для вас критические параметры, а не сколько вы их насобираете за секунду. Сама отправка события это дешевая операция и экономить их надо, если они уже не влезают в кадр.

Такое впечатление будто вы сами не до конца представляете содержание приведенных мне статей, скорость с которой гоняются данные.
А вы представляете? Основной затык у вас будет сеть, а не клиент.

[xdoom]

В моём тексте объединение понятий фреймфорка и MVC вызвано лишь использованием событий в обоих случаях.
Тема была создана только потому что не был уверен в этом:
Если обработка не вылазит за эти 50 мс, то тормозов не будет. По памяти тоже должно быть приемлемо. ... Сама отправка события это дешевая операция...
задача с синхронизацией это уже другая история, гораздо увлекательней, но о ней в другой раз.
Спасибо за дискуссию, успокоят меня наверное только тесты, как проведу отпишусь.

Добавлено через 14 минут
p.s. между модулями на самом деле json не гоняется, но от этого смысл не менятся. TanaTiX наверное опечатлося говоря о передаче событий через евенты, подразумевая данные.

[xdoom]

public function speedtest()
{
var eventDispatcher:EventDispatcher = new EventDispatcher()
eventDispatcher.addEventListener(Event.ACTIVATE,eventHandler)
var i:int = 10000000
var t:int = getTimer()
while (i--){
eventDispatcher.dispatchEvent(new Event(Event.ACTIVATE))
}
trace(getTimer()-t,ecount)
i = 10000000
t = getTimer()
while (i--){
eventHandler()
}
trace(getTimer()-t,ecount)
i = 10000000
t = getTimer()
while (i--){
ecount++
}
trace(getTimer()-t,ecount)

}
private var ecount:int
private function eventHandler(e:Event=null):void{
ecount++
}
13314 10000000
2773 20000000
778 30000000
Было понятно что события медленней, но не думал что более чем в три раза.
Фишка событий - это возможность цепляться на них сразу же нескольким обработчикам, когда этого не нужно, не понимаю причин их использовать. Прямых связей можно избежать другими способами.
По моему скромному представлению.

[Psycho Tiger]

Здорово. Осталось придумать, где бы в реальном проекте присобачить десятимилионные итерации

[xdoom]

м.б. кому будет интересно:
http://www.rivellomultimediaconsulting.com/as3-signals-introduction/

[artcraft]

эм, я вроде про сигналы сразу написал, неужели 2 недели потребовалось на поиск ссылки

еще есть турбосигналс (http://jacksondunstan.com/articles/585) (правда я не пробовал сам)