- Suslik
- Постоялец
Про Ogre2.0 - http://www.ogre3d.org/addonforums/viewtopic.php?f=17&t=30366
Пулл реквесты приветствуются, но лучше сначала там отписаться, если есть конкретные предложения.
Про RTT и ввод - надо смотреть RTT Layer Demo (там где 3д пульт управления с гуи на нем), но если коротко, то ввод обрабатывается внутри слоя отдельно, и видимо при вызове injectMouse*** событий надо иметь доступ к проверке, на каком мы сейчас окне и обрабатывать/не обрабатывать ввод.
Про архитектуру под неколько окон - думаю, что не позволит без существенных изменений, да и не хотелось бы включать столь редкую логику в ядро гуя. Если вдруг получится сделать отдельной платформой/внешним кодом, то сможем принять.
Altren
> Про RTT и ввод - надо смотреть RTT Layer Demo (там где 3д пульт управления с
> гуи на нем), но если коротко, то ввод обрабатывается внутри слоя отдельно, и
> видимо при вызове injectMouse*** событий надо иметь доступ к проверке, на каком
> мы сейчас окне и обрабатывать/не обрабатывать ввод.
может быть, мы о каких-то разных демо говорим? у меня при установке юниттестов появляется RTT Layer Demo, но оно выглядит как одно окно, на котором рендерится другое и не реагирует ни на какие контролы. куда смотреть?4
> Про архитектуру под неколько окон - думаю, что не позволит без существенных изменений, да и не хотелось бы включать столь редкую логику в ядро гуя. Если вдруг получится сделать отдельной платформой/внешним кодом, то сможем принять.
я бы не стал называть задачу столь редкой при таком огромном количестве реквестов на неё:
http://www.ogre3d.org/addonforums/viewtopic.php?f=17&t=14847
http://www.ogre3d.org/forums/viewtopic.php?f=1&t=78390
http://www.ogre3d.org/addonforums/viewtopic.php?f=17&t=12889
http://www.ogre3d.org/forums/viewtopic.php?f=25&t=82696
http://www.ogre3d.org/forums/viewtopic.php?f=3&t=40234
Да и, собственно, зачем делать синглтоном то, что синглтоном по сути не является? Почему-то осознание этой нехитрой истины дошло до разрабов того же CEGUI только в последнем релизе - им пришлось достаточно сильно пересматривать архитектуру, чтобы удалять синглтоны из инпута, из рутвиджетов и прочего. Я виню именно этот антипаттерн.
Ещё вопрос по коду - почему в mygui встречается существенное количество русских комментариев? Разве это не сказывается на негативно на международной репутации библиотеки?
Suslik
> может быть, мы о каких-то разных демо говорим? у меня при установке юниттестов
> появляется RTT Layer Demo, но оно выглядит как одно окно, на котором рендерится
> другое и не реагирует ни на какие контролы. куда смотреть?4
Да, я ошибся. UnitTest_Layers. В котором в результате получается вот такое: http://www.youtube.com/watch?v=J-FeieAFLGM
Про многооконность - я не видел, чтобы гуи подобного рода использовали в многооконных приложениях и считаю, что он для этого плохо подходит. Я бы рекомендовал использовать Qt или что-то подобное, если речь идет о окнах.
Про синглтон - уже очень давно было осознание того, что они не к месту, но обратная совместимость и отсутствие сильной необходимости отказа от них останавливало задачу.
Про комментарии - сам стараюсь писать только на английском в любых проектах, но не у всех есть такая возможность и порой пускай будут хоть на русском, нежели никаких.
Altren
> Да, я ошибся. UnitTest_Layers. В котором в результате получается вот такое:
> http://www.youtube.com/watch?v=J-FeieAFLGM
>
Да, но сэр, в этом примере у гуя только в одном таргете есть активные виджеты, поэтому с разделением инпута для каждого рендертаргета проблем нету. или я что-то не так понял?
Да, все верно. С разными рендер таргетами придется писать дополнительную логику, т.к. просто слоев и их перекрытия будет недостаточно.
Altren
то есть я правильно понимаю, что несколько интерактивных независимых формочек окне одновременно в зоне видимости даже в одном win32 сделать без модификации ядра не удастся? это же, вроде как, вовсе не экзотический случай, во многих играх бывает несколько ingame-интерактивных консолей да компьютеров?
Значит я неверно понял вопрос. В том демо можно добавить обычные элементы интерфейса на экран и они будут работать нормально, находясь "над" или "под" объектами на сцене (зависит от того, на каком слое находится элемент и порядка слоев).
слушай, ну неужели я настолько непонятно формулирую вопросы, что уже две страницы не получается найти на них ответы? не интересует "над" и "под". интересуют два гуя в рамках одного контекста, не лежащих в одной плоскости(то есть у них координаты мыши у каждого будут свои). отображать такие гуи, очевидно, можно посредством рендертаргетов. как каждому из них направить свои координаты для мыши?
В UnitTest_Layers это реализовано, надо смотреть там на логику в RTTLayer::getLayerItemByPoint и RTTLayer::getPosition. Если коротко, то обычный слой просто берет входные координаты, а RTTLayer из той демки делает raytracing.
Куда смотреть-то? Вот один метод:
ILayerItem* RTTLayer::getLayerItemByPoint(int _left, int _top) const { if ( !mIsPick) return nullptr; #ifdef MYGUI_OGRE_PLATFORM const MyGUI::IntSize& size = MyGUI::RenderManager::getInstance( ).getViewSize( ); bool result = pickPositionInObject( _left, _top, size.width, size.height, mTextureSize.width, mTextureSize.height); if ( result) { return Base::getLayerItemByPoint( _left, _top); } #endif return nullptr; }
Вот второй:
IntPoint RTTLayer::getPosition(int _left, int _top) const { if ( !mIsPick) return Base::getPosition( _left, _top); #ifdef MYGUI_OGRE_PLATFORM const MyGUI::IntSize& size = MyGUI::RenderManager::getInstance( ).getViewSize( ); bool result = pickPositionInObject( _left, _top, size.width, size.height, mTextureSize.width, mTextureSize.height); if ( result) { mOldPoint.set( _left, _top); } #endif return mOldPoint; }
Вот их реализация в базовом классе:
IntPoint OverlappedLayer::getPosition(int _left, int _top) const { return IntPoint( _left, _top); } ILayerItem* OverlappedLayer::getLayerItemByPoint( int _left, int _top) const { if ( !mIsPick) return nullptr; VectorILayerNode::const_reverse_iterator iter = mChildItems.rbegin( ); while ( iter != mChildItems.rend( )) { ILayerItem* item = ( *iter)->getLayerItemByPoint( _left, _top); if ( item != nullptr) return item; ++iter; } return nullptr; }
А теперь, внимание, вопрос. Какое отношение логика пикинга вообще имеет к обработке инпута? У меня вопрос был не как определить, в какую из форм мы ткнули мышью, а как инжектировать именно нужной форме сообщение о том, что в неё ткнули. В представленном коде вообще ничего про инжекцию не увидел.
Altren
Сегодня я скачал MyGUI, установил все зависимости указанные в readme - directX SDK, MS Visual C++ и все исполняемые файлы из каталога bin могли запускаться, но я не нашел в них ничего функционального, только некие примеры. Как нужно пользоваться программой и на сколько полезен MyGUI для дизайнера программного интерфейса?
If
> только некие примеры
было бы странно, если бы ты нашёл в примерах что-то кроме примеров
If
> Как нужно пользоваться программой и на сколько полезен MyGUI для дизайнера
> программного интерфейса?
поставь в cmake'е галку, чтобы билдил тулзы тоже. в комплекте есть визуальный редактор.
Все забываю спросить:
1) Есть ли внутренние оптимизации когда элементы перекрывают друг друга (панель перекрывает частично другую панель и еще сверху панелька перекрывает частично нижележащие)? Тут рисуется все от нижнего к верхнему или наоборот, но уже с тестом глубины? Как понимаешь, в первом случае получаем ненужный оверхед, а во втором случае хапаем проблем блендовыми и не блендовыми элементами.
2) Текстура одна, кнопка рисуется без бленда, а текст на ней с блендом. Мы получаем два дипа на одну кнопку или встроена логика компоновки без блендовых и блендовых элементов в два разных дипа? Опять таки что происходит когда такие элементы частично перекрывают друг друга?
Можно просто ткнуть в описание архитектуры рендера, сам не нашел.
Suslik
Инжектировать нужно из всех окон одинаково. Потом в слои будет попадать в логику пикинга и если мы тыкали в другом win32 окне, значит просто идем дальше.
Ну и конечно надо добавить делегаты на желаемые события, например eventMouseButtonClick для простых кнопок.
Важный момент - писать прийдется сравнительно много, демка Layers была приведена в качестве примера, т.к. ничего более подходящего готового нет.
If
> Как нужно пользоваться программой и на сколько полезен MyGUI для дизайнера программного интерфейса?
MyGUI - это в первую очередь GUI библиотека, т.е. чтобы была любая логика все равно нужно писать код. Если хочется набросать интерфейс, то конечно можно использовать LayoutEditor (идет в комплекте с собранными демками и по умолчанию он тоже собирается), но для дизайнера, который не пишет код, MyGUI точно не подходит.
Zloten
> Все забываю спросить:
> 1) Есть ли внутренние оптимизации когда элементы перекрывают друг друга (панель
> перекрывает частично другую панель и еще сверху панелька перекрывает частично
> нижележащие)? Тут рисуется все от нижнего к верхнему или наоборот, но уже с
> тестом глубины? Как понимаешь, в первом случае получаем ненужный оверхед, а во
> втором случае хапаем проблем блендовыми и не блендовыми элементами.
Теста глубины как такового нет, слои жестко заданы и упорядочены, а то что на одном слое рисуется в порядке создания.
Не отрисовывать нижнее нельзя, т.к. по факту почти все гуи хоть немного, но прозрачные.
Да и проверка на перекрытие порой дороже, чем простая отрисовка всего подряд. Не отрисовываются только элементы, которые точно не видны (стоит невидимость или вышли за край родителя/экрана).
> 2) Текстура одна, кнопка рисуется без бленда, а текст на ней с блендом. Мы
> получаем два дипа на одну кнопку или встроена логика компоновки без блендовых и
> блендовых элементов в два разных дипа? Опять таки что происходит когда такие
> элементы частично перекрывают друг друга?
> Можно просто ткнуть в описание архитектуры рендера, сам не нашел.
Есть два типа слоев - Shared и Overlapped.
Shared не знает про перекрытие и рендерит всегда в 1 или 2 дипа (если конечно текстура скина одна, если несколько, то 1 на текст, если есть + число текстур). 1й дип - скин, второй дип - все тексты (даже на разных кнопках и элементах). Т.е. если на таком слое две кнопки перекрываются, то тексты будут поверх обеих и выглядеть будет криво.
Overlapped знает про перекрытие, и у него та же логика, что и у Shared для каждого виджета на нем.
На всякий случай - в логике выше считаются только рутовые виджеты (созданные на слое, а не дочерние). Все дочерние виджеты, если это теоретически возможно, рисуются в том же дипе, что и родитель.
Altren
> Инжектировать нужно из всех окон одинаково. Потом в слои будет попадать в
> логику пикинга и если мы тыкали в другом win32 окне, значит просто идем дальше.
> Ну и конечно надо добавить делегаты на желаемые события, например
> eventMouseButtonClick для простых кнопок.
ок, видимо, я как-то непонятно изъясняюсь. пусть в игре есть два тачскрина(незавимисых), представляющих из себя игровой объект - интерактивную консоль. каждый из них представляет из себя один checkbox, находящийся посередине экрана. каждый тачскрин - отдельный рендертаргет. пользовательский код сам производит рейкастинг и возвращает, в каких координатах какого из мониторов сейчас находится мышь. далее, если игрок тыкает в середину одной из консолей, он попадает на чекбокс. каким образом нужно инжектировать событие о нажатии кнопки мыши, чтобы сработал только один из чекбоксов? речь уже даже не идёт о нескольких win32 окнах - обе консоли являются текстурами обычных трёхмерных объектов в рамках одного контекста.
Тема в архиве.