Взаимное исключение событий мышки
 

Всем привет.
Если кто-то встречался со подобным подскажите: есть две переменные, которые отслеживают зажата ли ЛКМ или просто сделан клик мышкой. Как можно взаимно исключить эти два события, чтобы признак зажатой кнопки проставлялся только после какого-то интервала что-ли? То есть приоритет был у одиночного щелчка.

А может проще в таком случае было бы реагировать на "отпускание" мышки? Просто у всех мышек и людей разные настройки / привычки. Вы на всех одинаковым интервалом не угодите.

Если на отпускание мышки, то получится двойное срабатывание, то есть сначала будет признак что мышка зажата, а потом сразу еще и признак что просто нажата кнопка. Либо опять же надо какое-то рациональное время вводить, сколько прошло между зажатой и отжатой кнопкой. Наверное лучше будет ввести счетчик, который будет отвечать за количество тиков пройденных между зажатием и отпусканием кнопки мышки.

Если, к примеру, взять эппловский UILongPressGestureRecognizer, то там эта самая задержка по-умолчанию равна 0.5 секунды.
Вам зачем вообще это всё?

Нет, вы не поняли. Одно событие происходит когда мышку отпускают, другое - когда нажимают. Нет двух событий, просто "клик" будет срабатывать когда мышку оптустили, а не нажали.

Может заменить прослушивание события CLICK на DOUBLE_CLICK? Оно, вроде, для таких вот случаев.

Зачем это все надо: пишу небольшую стрелялку, необходимо, чтобы объекты вылетали через одинаковый интервал времени, независимо от количества и вариантов нажатия мышки, то есть у персонажа есть некий стат, который отвечает за скорость стрельбы, его можно уменьшать либо увеличивать. Сейчас более мене вроде добился стабильности, но все равно что-то не так.

Выстрел -> перезарядка -> выстрел -> ...
Варьируется только время перезарядки. И не будет зависеть от скорости кликов.

Можно ли использовать setTimeout для таких случаев, так как пуля должна вылетать только на втором кадре анимации персонажа? Само собой скорость анимации зависит от количества ударов в секунду.

Зачем? Паузу не замучаетесь реализовывать? На каждый игровой тик проверяйте закончилась ли перезарядка.

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

а потом повсюду отписываться, а потом повсюду подписываться, а потом...

Именно!!
)))

К тому же незачем подписываться там где это не нужно - это упрощает задачу отписывания ;)

В играх вообще нет смысла городить подписку на глобальные таймеры. Это еще больше упрощает задачу отписывания :)

Один таймер это бонус к производительности и глобальной синхронизации по времени, как я понимаю.

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

Так а что я предложил то? Я без подробностей. А суть верная.

Обычно делается единый "обновлятор" (менеджер игрового цикла), который обновляет (например, вызывает у них метод update) состояния объектов. А не таймер на который все подписываются.

Вообще у меня сделано все через тик рэйты на каждое действие, которые зависят от статов игрока и количества кадров в секунду. По поводу setTimeout спросил, так как изначально наткнулся на него и попробовал что-то сделать с его помощью, но получилось весьма глюковато. Сделать конечно через что угодно можно, но все это держать в голове и не забыть обнулить где-то таймер для меня сложновато )) Если интересно, могу дать ссылку что получилось сейчас. Правда вот интересный феномен, garbage на десктопе показывает 0.130 , а на сайте около 10.000. С чем это может быть связано?

setTimeout не рекомендован к использованию. По-сути это костыль к Timer.

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

Например?

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

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

Я имел ввиду конкретный пример.

Та банально МВЦ - структура.
Если и есть какой-то глобальный обновлятор - то это будет нечто глобальное которое меняет все модели, чтобы вьюхи отрисовались.

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

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

Так модели или все-таки "может"? Моделям-то какое дело до каких-то там таймеров. Ладно это уже оффтоп пошел.

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

Но часто делают так что модель это тупо БД, которая ничего не умеет и только хранит данные. Потому и "может контроллер". Я в своих личных поделках использую правильный МВЦ в котором модель умная. На работе же у нас принята структура в которой контроллер - всему голова.

Кто вам сказал, что именно ваше видение MVC правильное? Тем более, что собственно "C" у вас отсутствует. И почему "по-правильному" у вас модели самообновляются. AI вы тоже в модели запихали?

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

Добавлено через 31 секунду
Я не хочу мвц обсуждать, просили пример - я дал.

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

По факту в вашей схеме (если я все правильно понял), "таймер" тот же "обновлятор". Единственная разница, что вместо "добавить участника" у вас "подписаться на событие обновления". Так?

Да я собственно с этого и начал. Тот же кран только в левой руке.

Только почему-то:

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

Ни о чем спор.
Это всё тонкости реализации, и если у кого-то это выливается в какие-то сложности, то к чему тут я.

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

Не вижу смысла продолжать дискуссию.

Как раз не "в общем и целом", а в частном. Естественно все зависит от конкретной реализации. И кстати ваша схема без дополнительных действий синхронна, а описанная мной схема не исключает асинхронности.

"В интернете кто-то не прав"