- war_zes
- Постоялец
war_zes
> Никаких UB там быть не может
зависит от инита
может в нем создается куча экранов, которые работали работали, а потом вдруг пересоздались.
типичный программист начинает задумываться, а почему пропадают данные, и начинает винить во всем С++ и искать ошибки тупой студии (язык и среду подставить свои)
Тред не читал, поэтому отвечаю сразу: типа стейты игры и "экраны" связаны только в самом простейшем случае. Во всех остальных правильней пилить отдельно гуй и отдельно игровую логику. А если пилить гуй, то там много окон, а не одно.
Ataman
> А если пилить гуй, то там много окон, а не одно.
эти окна всего лишь часть экрана.
не знаю как кому но мне концепция экранов понравилась больше чем стак окон, управлять этим легче.
верней для каждого экрана свой стак окон
Pushkoff
> не знаю как кому но мне концепция экранов понравилась больше чем стак окон, управлять этим легче
В терминах гуи-системы такие экраны просто родительское окно во весь контекст. Можешь включать/выключать их как хочешь.
Ataman
> В терминах гуи-системы такие экраны просто родительское окно во весь контекст.
> Можешь включать/выключать их как хочешь.
да я знаю, но мне все таки больше понравилась концепция экрана. то есть есть экран, я его называл стейтом, в нем стек виджетов, и события типа включили, выключили. ты знаешь что в фоне где-то под самым большим окном ничего не крутится и ничего не активно, рисовать ничего не надо и прочие прелести. в общем кому как, а мне понравилось так
еще прикольно организовывать поверх экранов слои, ну а в них уже стек виджетов
Pushkoff
> но мне все таки больше понравилась концепция экрана.
А ingame меню как реализуется? В смысле настройки в процессе игры.
Ataman
> А ingame меню как реализуется? В смысле настройки в процессе игры.
у стейта есть стек меню. это одно из меню этого стека
сам стейт сначала рисует игру, потом In game HUD, частью которого может быть ingame menu
вот именно в этом месте мне нравится концепция слоев
у нас есть 3 слоя, самый нижний это игра, потом хад, со своим стеком, потом ингейм меню. всякие менюшки хада никак не мешают ингейм меню, в плане если они хотят появится на верхнем слое, но не перекрыть случайно ингейм меню.
Zefick
> Делай, кто мешает, менеджер экранов тут при чём?
плюсую, я такое меню делал в битвах руинах - проблем не было, костылей тоже
Pushkoff
> может в нем создается куча экранов, которые работали работали, а потом вдруг
> пересоздались.
Смысл тут в том что в любой момент времени должен существовать только один созданный экран. Если созданных экранов будет два - это уже ошибка. Пользователь не должен звать любые методы модуля, тем не менее если он так сделает, должен происходить сброс данных при использовании модуля, иначе будет уже критичная утечка памяти (например в Init выделяется память в куче, если два раза вызвать, будет выделено два куска, старый при этом станет висячим). Почему может произойти двойной вызов? Пользователь не разобрался в коде и по привычке перед использованием вызвал метод Init. Затем менеджер его тоже вызвал.
То есть менеджер должен позаботиться о том, чтобы при смене активного экрана, старый экран был завершен, новый в случае если он по каким-то причинам был инициализирован, тоже должен быть завершен, и только потом заново пересоздан.
Для чего это сделано? А зачем например ресурсы меню в игре? А ресурсы игры в меню?
Ataman
> А если пилить гуй, то там много окон, а не одно.
Это не окно, это экран или сцена. В каждом модуле может быть полноценная гуи с тысячей окон:) Модуль все равно будет один
Вообще единственная проблема - я не знал как этот механизм назвать правильно, потому что это не сцена (хотя идея была именно из этого слова), сцена в гаймдеве имеет другое значение. Это не окно - потому что окон может быть много. Это не состояние, хотя это было бы близко. Вот и выбрал - экран, слово было взято из дизайндокументов, потому что там меню, игра и прочее назывались тоже экранами.
Pushkoff
> > Расскажи, какие симптомы и как лечить ?
> лечить, как сказал товарищ выше, ассертом
> а симптомы, кому как повезет
Видел пару раз как раз именно такой пример ... без assert - коммерческие продукты и всё такое ... это как с стаканом воды наполовину :)
Ataman
> типа стейты игры и "экраны" связаны только в самом простейшем случае. Во всех
> остальных правильней пилить отдельно гуй и отдельно игровую логику. А если
> пилить гуй, то там много окон, а не одно.
Да, ТК вводит всех в заблуждение
Ataman
> В терминах гуи-системы такие экраны просто родительское окно во весь контекст.
> Можешь включать/выключать их как хочешь.
Вот интересный момент - как обрабатывать всякие dropdown list и mouse capture ? Есть концепция desktop - у которого может быть Root Widget. Desktop и Widget не связаны иерархией.
Pushkoff
> у стейта есть стек меню. это одно из меню этого стека
Навскидку, почти всегда не стек, а граф. Или удобней делать не стеком из-за реюза.
Pushkoff
> у нас есть 3 слоя, самый нижний это игра, потом хад, со своим стеком, потом
> ингейм меню.
А потом тебе надо отрисовать модельку поверх слоя ингейм меню, а поверх нее табличку с описанием и т.д. и т.п.
Не проще ли один раз общую логику оконной системы заюзать?
innuendo
> как обрабатывать всякие dropdown list и mouse capture ? Есть концепция desktop - у которого может быть Root Widget.
Ну да, у меня, например, так и есть, только названия контекст и десктоп (специальное окно). Дропы и ввод делаются через контекст, в котором вся логика управления окнами и ее стейт.
Ataman
> Ну да, у меня, например, так и есть, только названия контекст и десктоп
> (специальное окно). Дропы и ввод делаются через контекст, в котором вся логика
> управления окнами и ее стейт.
Названия могу отличаться.
Просто когда вся логика внутри RootWidget - оный очень сильно раздувается :)
Pushkoff
> да я знаю, но мне все таки больше понравилась концепция экрана. то есть есть
> экран, я его называл стейтом, в нем стек виджетов, и события типа включили,
> выключили.
Определиться желательно, что есть модуль ибо ...
innuendo
> Просто когда вся логика внутри RootWidget - оный очень сильно раздувается :)
Дык там только картинко (и то не всегда). Системная логика менеджмента дочерних окон в базовом классе окна. А в контексте системная логика работы гуя в целом. Специфическая для приложения - в окнах приложения.
Тема в архиве.