Oxygine 2D C++ фреймворк (9 стр) / Утилиты / Форум / Проекты / GameDev.ru

Обещал написать про новую библиотечку oxygine-frame (открыта, MIT лицензия)
https://bitbucket.org/frankinshtein/oxygine-frame
собранная демка для Windows

Может быть использована для создания системы диалогов/экранов и перехода между ними.
Ключевая особенность - все построено на "блокирующем" коде, api которого есть в oxygine (namespace blocking).
Кто-то делает свои сложные менеджеры сцен и стеки-списки добавленных сцен, удобряя все колбеками.

А при моем подходе стек окон - это нативный call stack и он же по своей сути менеджер сцен. Код выполняется последовательно, ясен и легко отлаживается.

Oxygine-frame предоставляет:
- базовый класс Frame от которого нужно наследовать свои диалоги/экраны (смотри header)
- набор из нескольких блокирующих transition* функций для перехода между ними
- небольшую коллекцию стандартных переходов между экранами и диалогами (через фейд, вращение, выезд, масштабирование и тд).

В своем классе от наследованном от Frame можно перегрузить методы типа preShowing, postShowing, preHiding, postHiding и тд.
К примеру в preShowing можно настроить внешний вид экрана, загрузить ресурсы, а в postHiding удалить их.

вот псевдокод функциональности которой можно добиться:

string player_name = showInputNameDialog(); //покажем диалог и дождемся его закрытия
if (player_name.empty()) //игрок ничего не ввел
    exit(); //выходим
else
    showHelloPlayerDialog(player_name);//покажем приветствие

а так бы, например, могла выглядеть реализация с использованием oxygine-frame

string showInputNameDialog()
{
      spMyDialog dialog = MyInputNameDialog::getInstance();
      if (transitionShowAsDialog(dialog, new TransitionFade, new TransitionMove).action == "btn_ok")
          return dialog->getPlayerName();

      return "";
}

где transitionShowAsDialog функция из oxygine-frame, в которую мы передали наш диалог и способ как он должен появляться и прятаться, а остальное (методы, классы) ваш собственный код.

showHelloPlayerDialog может быть такой:

void showHelloPlayerDialog(string name)
{
       transitionShowAsDialog(new MessageBoxDialog("hello player" + name));
}

если вдруг диалог перестал быть диалогом и перерос в целый экран, то достаточно заменить вызов transitionShowAsDialog на transitionShowFrame, который будет автоматически прятать и восстанавливать предыдущий Frame.

Хочу продемонстрировать общий подход и его преимущества на более реальном примере из жизни:

//lets show game frame(screen)
spGameFrame game = GameFrame::getInstance();
game->setup(level, someSettings, background);//setup game
transitionShowFrame(game);//running game frame
//game ended
//save progress
saveGame();

if (game->isWon())
{   
       //player won
       if (game->getScore() > 1000)
       {
            //Earned a lot of points? Lets show nice screen and present good stuff
            addPrize2player(something);
            PrizeFrame::getInstance()->setup(something);
            transitionShowFrame(PrizeFrame::getInstance());
       } 
       //show scoreboard
       spScoreFrame score = ScoreFrame::getInstance();
       score->setup(game->getScore());
       if (transitionShowAsDialog(score).action == "btn_send2server")
       {
              //player clicked button "send record to server", lets do it
              sentScore2ServerAsync(game->getScore(), game->getLevel());
       }
}

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

Frankinshtein
Постоялец

#125
23:53, 18 фев 2013

мало кто заглядывает:) поменял тему, посмотрим что будет

DanQuimby
Постоялец

#126
0:06, 19 фев 2013

Frankinshtein
> мало кто заглядывает:) поменял тему, посмотрим что будет
не правда слежу за твоим проектом.
Шеф думает проект под win32\qt перенести на все платформы.
Смотрю на ndk и твой проект.

dmitryhryppa
Постоялец

#127
1:24, 19 фев 2013

Frankinshtein
> мало кто заглядывает:)
Присоединяюсь к DanQuimby, я тоже в теме.

> поменял тему, посмотрим что будет
Отличный фреймворк, да.

Frankinshtein
Постоялец

#128
11:53, 19 фев 2013

DanQuimby
k-tormozit
спасибо, но просто хотеть использовать пока недостаточно)
нужны выпущенные или хотя бы запущенные проекты

dmitryhryppa
Постоялец

#129
13:12, 19 фев 2013

Frankinshtein
> нужны выпущенные или хотя бы запущенные проекты
Я тебе писал в скайп ) Нравится схожесть с AS3.
Делаю на твоем фреймворке игру, которая будет готова в начале марта. :)

jaguard
Постоялец

#130
18:30, 19 фев 2013

Чисто идеологически - зачем еще один движок с этими богомерзкими флеш-подобными спрайтами? Неужели кокоса мало?

Почему вообще создатели этих самых движков думают, что самому следить за объектом и вызывать ему sprite->Draw(x,y) сложнее, чем пихать его в сцену, как-то его потом отслеживать, ручками обновлять позицию/поворот, а чтобы изменить порядок рендера не написать тупо zIndex = X;, а писать какую-нибудь хрень типа Scenegraph[zIndex].removeChild(this);
zIndex = newZindex;
Scenegraph[newZindex].AddChild(this);
(для этого естественно заводить массив сценграфов, или вообще делать всей сцене тотальный ремув, пересортировывать ручками и обратно на сцену добавлять).

В целом - прочитал шапку, так и не понял какие платформы поддерживаются.

Frankinshtein
Постоялец

#131
19:15, 19 фев 2013

jaguard
> Чисто идеологически - зачем еще один движок с этими богомерзкими флеш-подобными
> спрайтами? Неужели кокоса мало?
зачем нужен в игре сценграф? Может ты не пробовал работать со флешем? Это очень удобный инструмент, особенно для игр

>>Почему вообще создатели этих самых движков думают, что самому следить за объектом и вызывать ему sprite->Draw(x,y) сложнее, чем пихать его в сцену, как-то его потом отслеживать, ручками обновлять позицию/поворот
даже не знаю что тут написать...
Все зависит от типа игры, если эта казуалка с красивыми сложными анимациями, переходами, фейдами и тд. То как ты все это менеджить ручками будешь?
Работать со сценграфом на порядок удобнее, самый простой пример: создал спрайт настроил анимацию, добавил ему твин, очередь из твинов, выставил автоматическое удаление, запустил и забыл. Он сам отработает и что нужно сделает.
Код получается локальным, легко изменяемым и поддерживаемым.

Представь сложную сцену в игре с множеством элементов UI, что-то мигает по альфе, какая-то надпись по экрану плывет плавно появляясь, что-то сбоку выезжает и т.д. Ну как за всем этим уследить, если ты собираешься ручками везде писать sprite->draw(x, y)?
Это слишком низкоуровневый подход и нужен только в узких местах, где большое количество однотипных объектов, например, частицы.

>>, а чтобы изменить порядок рендера не написать тупо zIndex = X;, а писать какую-нибудь хрень типа Scenegraph[zIndex].removeChild(this);
Сравнение с кокосом (2dx) конечно не очень уместно тут, ибо он убог. У меня чтоб изменить порядок, достаточно написать
sprite->setPriority(index);

>>В целом - прочитал шапку, так и не понял какие платформы поддерживаются.
платформы Marmalade и SDL2, они дружат с ios, win, mac, android, blackberry и еще пачка других

jaguard
Постоялец

#132
22:54, 19 фев 2013

Frankinshtein
>
> зачем нужен в игре сценграф? Может ты не пробовал работать со флешем? Это очень
> удобный инструмент, особенно для игр

Я работал с флешем. Долго плевался на фреймворк и долго писал всякие бессмысленные классы, долго плевался на неудобный Eclipse который Flex Builder, и тд.

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

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

> Работать со сценграфом на порядок удобнее, самый простой пример: создал спрайт
> настроил анимацию, добавил ему твин, очередь из твинов, выставил автоматическое
> удаление, запустил и забыл.

Не бывает в играх никаких "просто так спрайтов". Да и не только в играх. Это всегда какие-то физические сущности - игровые объекты, партиклы, кнопки, диалоговые окошки, и прочая. Кроме партиклов, которые и так используются подобным образом, безо всяких там эддчайлдов, остальные сущности не получится просто "создать, настроить анимации и удалить". У них какой-то смысл всегда есть, и он сложный. Поэтому это не спрайт, а класс, который в себе содержит спрайт и который знает как себя рисовать, и при этом еще делает что-то полезное.

Frankinshtein
> Представь сложную сцену в игре с множеством элементов UI, что-то мигает по
> альфе, какая-то надпись по экрану плывет плавно появляясь, что-то сбоку
> выезжает и т.д. Ну как за всем этим уследить, если ты собираешься ручками везде
> писать sprite->draw(x, y)?

Декомпозицией. Поотключаю все сущности и начну включать по одному (отдельно партиклы, отдельно кнопки, итд). 5 минут и виновник найден. А вот как ты будешь в своем спагетти из аддчайлдов и очередей твинов разбираться - это для меня загадка.

Frankinshtein
> Сравнение с кокосом (2dx) конечно не очень уместно тут, ибо он убог. У меня
> чтоб изменить порядок, достаточно написать
> sprite->setPriority(index);

Вот и во флеше в AS2 были удобные zIndex у объектов. Зато в третьей их нет, а есть только addchild, и чтобы поменять объекту zIndex, нужно делать сначала 100500 removeChild, а потом 100500 addchild обратно.

Frankinshtein
> платформы Marmalade и SDL2, они дружат с ios, win, mac, android, blackberry и
> еще пачка других

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

dmitryhryppa
Постоялец

#133
23:18, 19 фев 2013

jaguard
> Вот и во флеше в AS2 были удобные zIndex у объектов. Зато в третьей их нет, а
> есть только addchild, и чтобы поменять объекту zIndex, нужно делать сначала
> 100500 removeChild, а потом 100500 addchild обратно.

Да ну неее.... setChildIndex(mySprite, 0), всего-то.

Frankinshtein
Постоялец

#134
0:32, 20 фев 2013

jaguard
> А как мне поможет в этом твой сценграф? Пути собственно два - либо делать в
> каком-нибудь отдельном инструментарии, либо таки да - ручками. Как это все
> относится к сценграфу мне все еще непонятно.

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

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

jaguard

> Не бывает в играх никаких "просто так спрайтов". Да и не только в играх. Это
> всегда какие-то физические сущности - игровые объекты, партиклы, кнопки,
> диалоговые окошки, и прочая. Кроме партиклов, которые и так используются
> подобным образом, безо всяких там эддчайлдов, остальные сущности не получится
> просто "создать, настроить анимации и удалить". У них какой-то смысл всегда
> есть, и он сложный. Поэтому это не спрайт, а класс, который в себе содержит
> спрайт и который знает как себя рисовать, и при этом еще делает что-то
> полезное.

1. игровые объекты это одно, их нужно реализовать в зависимости от задачи, внутри может быть и низкоуровневый sprite->draw(x, y)
2. партиклы тоже самое
3. А вот "кнопки, диалоговые окошки, и прочая" уже отлично вписываются в эту схему и легко анимируются.
Окошко у него есть чайлды, окошко должно выезжать по хитрому, и прятаться
в кнопке тоже чайлды: текст, иконка, текст может быть разного цвета, моргать, кнопка может быть задисейблена, а при нажатии на нее, например, она красиво моргнет.

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

А, когда делаешь все ручками может все и работает чуточку быстрее, жрет меньше памяти, но стоит ли оно того? Я считаю, что нет.
Странно это отрицать. Сценграф есть Сocoa, Unity и даже для окошек в winapi.

>>Декомпозицией. Поотключаю все сущности и начну включать по одному (отдельно партиклы, отдельно кнопки, итд). 5 минут и виновник найден. А вот как ты будешь в своем спагетти из аддчайлдов и
У меня есть tree inspector. Если вдруг что-то где-то потерялось, я всегда могу заглянуть в него и проверить.

>>очередей твинов разбираться - это для меня загадка.
С ними не надо разбираться, написал 1 раз и оно работает, если нужно подправил время или аргументы. Любые сложные последовательности анимаций занимают пару строк кода.
А ты видимо на каждый чих по стейт машине заводишь будешь?

>>Вот и во флеше в AS2 были удобные zIndex у объектов. Зато в третьей их нет, а есть только addchild, и чтобы поменять объекту zIndex, нужно делать сначала 100500 removeChild, а потом 100500 addchild обратно.
в ac3 есть insertChild after/befor

>>Понял, значит собственного движка у тебя нет, есть просто маленький фреймворк
в заголовке написано фреймворк. Зачем делать самодельную платформу, которая будет клоном того же SDL, только не протестированной людьми и глючной.
маленький? я бы не сказал что он маленький, видимо ты не читал про фичи на первой странице.

>>для превращения удобного мармелада в неудобный флеш :).
это голословное утверждение. У меня не клон флеша, а просто провел аналогию для большей понятности, из флеша почти 1 в 1 позаимствованы только эвенты.