|
|
|||||
Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
|
Приостановить слушатели событий
И ещё вопрос, друзья, по слушателям событий.
Есть основной экран игры, на нём элементы пользовательского интерфейса, на них висят слушатели событий клика. Игрок вызвал главное меню, меню появилось на экране. До тех пор, пока пользователь не вернётся в игру, никакие элементы игрового интерфейса не должны действовать. Вопрос, как наиболее технологично временно приостановить их работу, не убирая с экрана? Снимать слушатели событий, выставлять EnableMouse в false? Уверен, что подобную проблему многие решали и имеют обоснованные рекомендации. Спасибо.
__________________
Не сломано - не чини! |
|
|||||
Нуб нубам
модератор форума
Регистрация: Jan 2006
Адрес: Бердск, НСО
Сообщений: 6,445
|
Ну так, если у тебя есть контроллер игрового интерфейса (HUD) логично в нем иметь методы activate/deactivate, контроллеры чуть ли не для этого и придумали)) А вот "жизнь" в модели ты как останавливаешь, или у тебя нет таймера? Ну, я имею ввиду, что такие вещи как "пауза" в игре должны быть естественным образом предусмотрены, если это не "пятнашки" конечно. Должен же быть какой-то "главный" контроллер, не игрового процесса, а Игры в смысле Приложения.. и способность создавать, запускать, останавливать и начинать заново Игровой процесс (и сохранять и загружать сейвы) — его непосредственная задача. Это как плеер, в котором проигрывается игра.
Возможно, ты работал над игровым процессо м все это время и не задумывался ни о какой "паузе". Ну, значит пришло время подумать)) ведь надо не только мышь оглушить, но и все процессы остановить. чтобы враг там тебя не растерзал, пока ты в меню ковыряешься.
__________________
Reality.getBounds(this); |
|
|||||
Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
|
У меня игровая механика немного иная. Читаешь текст, смотришь арт, выбираешь вариант действий. После этого Модель всё рассчитывает, создаёт вектор инструкций для Вью и отправляет событие. Вью его хватает и разбирает поштучно: обновляется текст, обновляется арт, всякие шкалы-иконки каждого из персонажей. Ну и так далее. Так что главного таймера как такового нет.
На счёт методов activate/deactivate разумно, но я имел в виду вопрос реализации на более приземлённом уровне, внутри этих методов. Нормально будет снимать, а затем обратно вешать слушатели событий или есть какие-то более элегантные способы?
__________________
Не сломано - не чини! |
|
|||||
Нуб нубам
модератор форума
Регистрация: Jan 2006
Адрес: Бердск, НСО
Сообщений: 6,445
|
А, могут быть визуальные проблемы из-за обработки мыши ВНУТРИ вью — всякие там ховеры/клики на кнопках и звуки.
И это уже проблема Вью, согласен, для нее подходит определение "более приземленного уровня". Это не имеет к MVC отношения, делай как удобно на уровне вьюхи.
__________________
Reality.getBounds(this); Последний раз редактировалось Wolsh; 05.07.2021 в 15:41. |
|
|||||
Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
|
Wolsh, да, всё верно, это внутри Вью. Но суть моего вопроса в способе приостановки слушателей. Если делать в лоб, то можно создать метод deactivate(), который вручную обратится ко всем кнопочкам, которые я в нём напишу, и снимет слушатель. Но мне не очень нравится такой подход. Неохота держать в голове необходимость ручного добавления в deactivate каждой новой кнопочки. Вот думаю...
И ещё, ты наверняка видел мои вопросы в соседней теме на счёт кто кого создаёт. Я чего-то уже всю голову сломал, мне нужен совет. Поясню. Если речь идёт о чисто внутриигровых компонентах, которые сами по себе имеют иерархическую структуру (например MVC персонажа внутри MVC игрового процесса), то описанный подход (вью создаёт вью, модель - модель) работает прекрасно. Но чуть только вопрос переходит в плоскость более крупных и не связанных естественной иерархией частей, то пока полный затык. Например, вызов главного меню из игры, или журнала с квестами и статистиками персонажей.
__________________
Не сломано - не чини! |
|
|||||
Нуб нубам
модератор форума
Регистрация: Jan 2006
Адрес: Бердск, НСО
Сообщений: 6,445
|
Ну тут как однозначно скажешь? Зависит от твоей реализации. Понятно, что самый простой способ — кинуть mouseEnabled/mouseChildren прямо на контейнер. Ну а если например кнопочки умеют показывать визуально свое неактивное состояние, то их же надо лично каждую в это состояние перевести. Или, например, однажды возикнет странное желание отключить НЕ ВСЕ кнопочки.
Отписываться, потом опять подписываться, это конечно диковато, как будто ты создаешь партизанский бестелесный контроллер внутри Вью. Я бы использовал для дисплейных объектов дисплейные методы (mouseEnabled/mouseChildren) и не парился. Тебе же нужно не распределение Событий отредактировать, а тупо спрятать объекты от мыши.
__________________
Reality.getBounds(this); |
|
|||||
Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
|
Спасибо. Вот и я вчера пришёл к тому же. Посмотрел код и вспомнилось, что помимо нажатий, у меня ещё висят слушатели событий наведения мыши, плюс отдельно иконки регистрируются в классе Tooltips, а там ещё чуть ли не 3 слушателя. Всё это снимать и ставить - порнография.
__________________
Не сломано - не чини! |
|
|||||
Регистрация: Oct 2006
Сообщений: 2,281
|
может ляпну не в тему, но обычно UI можно заблочить прозрачным спрайтом на весь экран
|
|
|||||
Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
|
Хм... Какая-то, господа, у меня пока фигня получается.
Вопрос заглушить решился просто - назначением mouseChildren = false самому старшему в иерархии контейнеру. Но проблема возникла в момент, когда всё потребовалось вернуть обратно. Вариант присвоить true почему-то не работает. Пока не понимаю, почему...
__________________
Не сломано - не чини! |
|
|||||
Регистрация: Oct 2006
Сообщений: 2,281
|
попробуй поиграться с mouseEnabled. Он обычно в паре с mouseChildren идет
|
Часовой пояс GMT +4, время: 06:27. |
|
« Предыдущая тема | Следующая тема » |
Опции темы | |
Опции просмотра | |
|
|