Oxygine 2D C++ фреймворк (56 стр)

Что лучше использовать в данном движке при написании клиента игры на вебсокетах?

Уважаемые мэтры, вижу многие уже успели попользоваться движком Oxygine, помогите советом и файлом.

Начну с вопроса,
Реально ли пересобрать с нуля (без использования "проектов" CMake и пр.), без компилирования SDL, сам Oxygine и какой либо из примеров (конечно, при наличии готовых dll файлов SDL)?
Если да, то можно ли получить файл libSDL2.dll, который отсутствует в единой сборке (all-in-one), но вроде должен бы там быть?
Т.е. я хотел бы знать, сильно ли много нюансов в проекте Oxygine, которые нужно будет учесть при такой сборке проекта с нуля и есть ли / будет ли доступна информация об этих нюансах?
Задаю вопрос, т.к. с учетом всех факторов, на данном этапе, нужно решить или добить использование Oxygine в моей конфигурации, либо менять, а заодно и актуализировать саму конфигурацию под Oxygine (или какой другой 2D движок).

Моя конфигурация системы:
Win 8.1 (x64)
MinGW+MSYS  (x32)
Eclipse 4.5  (x64)
без MS VS

В этой конфигурации без проблем запускаю SDL-приложение, с динамическим подключением библиотеки SDL 2.0, используя SDL.dll и исходники из единой сборки (all-in-one) с сайта Oxygine.org. Графика работает на простейшем уровне (движущиеся пиксели), но создавать свой движок не хочется.

Далее подробности и мои соображения на этот счет.

Попытался, в соответствии с Readme-файлами и папками, "восстановить" проекты сначала просто SDL библиотеки, а затем и для примера Demo из этой же сборки. Для этого использовал проекты CMake. Но неудачно, могу привести ошибки, которые выдает make. Компиляция SDL затыкается на 39% на audio/winmm, сборка примера Demo проходит 100%, но потом выдает ошибку из-за неизвестных функций (видимо, не хватает файла libSDL2.dll).

При этом не нашел в единой сборке этого файла: libSDL2.dll, цитата из CMake+MinGW.txt
"...copy libSDL2.dll and dlls from oxygine-framework\oxygine\third_party\win32_mingw\dlls\..."

Кроме того, прочитал здесь:

https://wiki.libsdl.org/Installation
что SDL больше не будет поддерживаться при компиляции на MinGW32, дословно:
"As of SDL 2.0.3, the codebase still compiles on Cygwin and MingW32, but we expect these to stop working in the future. MingW64 is still supported (and despite the name, can also build 32-bit binaries)."
- это для Windows XP/Vista/7

Для Windows 8.1 - вообще написано, что "в теории" должно работать при наличии установленного софта MS, цитирую "At least in theory, this should Just Work if you have Windows 8.1, Visual C++ 2013, and the Win8/WinPhone/etc SDKs installed"
поэтому надежды, что я смогу заново собрать SDL с доппараметрами у себя на системе - нет. А ставить кучу софта от MS и еще непонятно с каким результатом ради единственного файла библиотеки не хочется.

И вообще руководство по компилированию SDL2 на сайте SDL отсутствует, есть архивная статься про SDL1 и то не на самом сайте SDL (жива только ссылка на вебархив). В общем как-то грустно у SDL с Windows.

В худшем случае, вообще думаю о переходе под Linux всего окружения, т.к. дальше у MS - Win10, который пугает своей политикой обновлений, которые нельзя отключить. Тем более конечная цель - не юзерские игры, а физ. симуляции с тяжелыми расчетами (впереди еще подключение библиотеки для работы с большими числами).

Paulo
1. Самый первый вопрос, зачем мучить себя и не взять бесплатную Visual Studio Express.
2. Как все собрать? по шагам, постепенно, через гугл. Вряд ли кто-то тебе скажет больше без конкретных ошибок
в readme/CMake+MinGW есть инструкция как все собрать, СДЛ там тоже собирается

Frankinshtein
> 1. Самый первый вопрос, зачем мучить себя и не взять бесплатную Visual Studio
> Express.
> 2. Как все собрать? по шагам, постепенно, через гугл. Вряд ли кто-то тебе
> скажет больше без конкретных ошибок
> в readme/CMake+MinGW есть инструкция как все собрать, СДЛ там тоже собирается

И все-таки, есть ли готовый файл libSDL2.dll для сборки c MinGW?

По п.1 ответа - да, как запасной вариант и это можно, но дальше что? А если и там проект не заработает (не забываем, что VS тоже не стоит на месте), еще и с VS разбираться? И далее совсем переходить в бесплатную VS или мигрировать проект (опять же) в Eclipse? Т.е. отсюда, могу ли я сделать вывод, что собирая самостоятельно сразу в Eclipse-е весь проект Oxygine я потрачу намного больше времени, чем буду заниматься любовью с продуктами MS?
Вопрос риторический, т.к. даже если это и так, я сейчас предпочту потратить больше времени на разбор всего проекта, чем на изучение особенностей MS, т.к. цель - все-таки изначальная кроссплатформенность и т.к. потом знания по проекту движка могут быть полезны, что не скажешь о MS (для меня).

По п.2 - так до сих пор и жил и планировал. С SDL вопросов нет (ну, почти нет), соберу, если действительно ни у кого не найдется рабочего файла libSDL2.dll. Больше пугает малораспространенность Oxygine: а вдруг google здесь уже не поможет оперативно решить проблемы? Не забываем, что моя цель использования ГОТОВОГО движка - сокращение времени решения своей задачи с приемлимым качеством результируещей программы. Да, я понимаю, что это мои проблемы неопытного начинающего, который пытается использовать чужой проект, но я бы все же пропустил этот важный этап "разбора чужого кода", настолько, насколько это возможно.

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

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

И еще важно, очень неправильно, делать то, что автор кода (я про SDL) явно указал "может не поддерживаться": компиляция SDL (начиная с версии 2.0.4) с использованием MinGW32 не гарантируется ни разу. Без проблем бы перешел на MinGW64 (хотя здесь уже тоже есть негативный момент), опять же, если бы быть уверенным, что и Oxygine можно будет с ним собрать и откомпилировать.

Paulo
> И все-таки, есть ли готовый файл libSDL2.dll для сборки c MinGW?
нету

на все что ниже "абы да кабы", ничего тут ответить не могу

если есть конкретные ошибки, то спрашивай

Нужны отзывы в данной теме, неужели не интересно никому?
https://gamedev.ru/projects/forum/?id=234646
для oxygine-freetype юзеров есть уже подключенная font effects в отдельной ветке

Frankinshtein
> если есть конкретные ошибки, то спрашивай

Ошибок пока нет, но хотелось бы подтвердить, что делаю все правильно. Просьба глянуть на свойства сгенеренной библиотеки SDL под Oxygine, нет ли там пропущенных необходимых опций. Особенно смущает строчка "--  DIRECTX                (Wanted: ON): OFF"

Для информации:
Пока получилось "засунуть" SDL проект в Eclipse и скомпилировать библиотеку с приведенным отчетом. С учетом всех нюансов, использовал версию SDL2-2.0.1.
Также получилось скомпилировать библиотеку и чисто из оболочки MinGW стандартным для SDL способом, описанным у них на сайте.
НО! При этом при компиляции одной и той же библитеки через Eclipse я получаю файл lidSDL2.dll, а через оболочку MinGW - только файл SDL2.dll, остальные файлы аналогичны.

Frankinshtein
> если есть конкретные ошибки, то спрашивай

В общем начал я с попытки собрать пример Demo (в соответствии с readme\CMake+MinGW.txt). Просьба подсказать, что может быть не так, если я застрял на вот такой ошибке:
D:/MyDocs/home/LUNA/clib/oxygine-framework/oxygine/src/core/file.cpp:67: undefined reference to `SDL_GetPrefPath'

Причем эта функция уже есть в версии SDL 2.0.1 и в исходниках SDL, которые я имею и в папке SDL рядом с Oxygine и в папке C:\MinGW\include\SDL2\

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

это из инструкции:

If you are using:
  - SDL2:
    1. Download latest SDL2 source snapshot from http://libsdl.org/hg.php

тут нет ни слова про 2.0.1 которая несколько лет назад вышла

Два дня танцевал с этим движком и mingw, но таки собрал. Win 7 SP1 64bit, Codeblocks 17.12 со встроенным mingw, CMake 3.11.3.
Качал фреймворк который вместе с SDL2 шел. SDL2 собственно влет собирался без проблем.
Не знаю, но кажется автор вообще не заморачивался проверять сборку под чем-то кроме VS. В винде с mingw на линковке сыпалось, pthread из mingw конфликтовал с pthreadVCE2 из third party движка. Они чудесным образом одновременно подключались. Точнее все проще, второй явно был указан в CMakeLists, а первый неявно линковался, кажется вместе со стандартной библиотекой.
Под линуксом собираеться нормально, но вот сами скрипты в винде видимо написаны, приходилось в линуксовый формат конвертировать.
Пробовал собрать другой сборкой, свежей mingw64, с потоками проблем не было .. хотя возможно до них дойти не успело. Все опять же на линковке сыпалось. Только теперь из-за разных архитектур библиотек, в third party лежали под i386, а mingw64 клепал x86-64 .. не срослось. Хотя, если самому скачать и собрать все те библиотеки, то наверное это бы сработало. С ключем -m32 двиг компилился, но почему-то не собирался SDL2, хотя тоже компилился. Забросил это дело и вернулся к mingw32 из Codeblocks.
Собственно, как собрать. Надо поправить CMakeLists, который в корне движка лежит. На 166 строке исправить "pthreadVCE2" на "pthread", так мы любезно разъясним, что нужно линковать, а что нет. Однако у меня почему-то на линковке все равно конфликт был, тогда нужно снести/перенести/переименовать ту библиотеку, что в third party лежит (папку "\win32_mingw\pthreads" и на всякий случай сам файлик в "\win32_mingw\libraries\pthreadVCE2.lib").
Однако сборка все равно не собиралась, линковщик не находил функцию "GetProcessMemoryInfo@12". Исправить можно добавив в CMakeLists в том же самом месте новую строчку "psapi". Это подключит нужную библиотеку.
Только после всего этого демо пример собрался. Правда при запуске обрадовал ошибкой об отсутствии msvcr110.dll, а это особенно забавно после сборки всего на mingw, похоже какая-то из библиотек ее использует. Лечится установкой vc redistr, в моем случае почему-то на компе не было именно 32-битной 2012 года.

SphynX
> Забросил это дело и вернулся к mingw32 из Codeblocks.

А после этого можно забрасывать и сам движок, т.к. он должен собираться по мнению автора с последней версией SDL (сейчас это 2.0.8), которую тоже нужно заново для себя компилить под свой проект, которая (т.е. SDL) в свою очередь требует использования MinGW64. SDL же из фреймворка собирается т.к. это последняя версия (2.0.4) которая тестировалась еще собиралась с MinGW32 (и которая еще не тестировалась в Win 8.1 и 10, как я понял). Точнее тестировалась последней 2.0.3, а в 2.0.4 уже говорилось об отсутствии гарантии работы с MinGW32 и переходе на MinGW64.
Конечно, это относится только к извращенцам, которые пытаются на Windows пользоваться MinGW, да еще и для мультиплатформенных приложений.

Вывод из всего опыта установки Oxygine:
Проект Oxygine максимально не подходит по сборке для использования в Eclipse с MinGW на Windows:
- структура проекта его примеров содержит папки на несколько уровней выше базовой папки примера, что не соответствует идее Eclipse-а, когда проект полностью хранится в своей папке, или идее CMake-а, когда основной файл СMakeLists.txt также должен храниться в верхней корневой папке;
- сам фреймворк широко использует средства макросов с фиксированным расположением папок исходников, что в случае переноса в Eclipse потребует множества настроек в самом Eclipse / либо потребует отказаться от всех удобств предоставляемых Eclipse и фактически работать в CMake/другом IDE;
- использование фреймворка требует перекомпиляции SDL вручную с доппараметрами. При этом не все необходимые DLL находятся в сборке фреймворка, а те которые есть – неизвестны версии mingw которыми они были получены (что в последних версиях MinGW, как я понял, имеет немалое значение). При этом на сайте SDL категорически не рекомендуют сборку SDL с нуля и только в тех случаях когда это обосновано и проверено автором (т.е. требуется погружение в исходники SDL). Кроме того, фреймворк требует использования «последней версии SDL», а сайт SDL требует использования MinGW-w64 для сборки для текущих версий (2.0.8), что не указано на данный момент в описании Oxygine.
-  при необходимости отображения 3D сцен, потребуется полный переход на новую платформу; с учетом же времени, необходимого для "въезжания" в Oxygine, весь наработанный опыт с Oxygine окажется бесполезным для варианта 3D сцен;
- нет помощи от пользователей, уже использующих Oxygine с Eclipse и MinGW (что теперь неудивительно).
- как итог – Oxygine скорее больше подходит для написания своего движка 2D (что в принципе и следует из слова фреймворк), чем для использования в качестве готового движка для начинающих.
Буду пробовать что-нибудь попроще, что имеет более универсальный и простой вид (ООП подход с простым подключением), хотя может быть и уступает по производительности и охвату систем. Например, Irrlicht.

Paulo
что же за мазахисты такие которые используют на винде Эклипс и MinGW, когда есть даже бесплатная VS.
весь, даже не весь, а ВСЕ комментарии, что ты тут оставил сводятся к тому что: я хочу использовать гиктулсы, но не умею ими особо пользоваться и не могу скомпилировать SDL ими, как скомпилировать СДЛ правильно? почему тут компилирую имя такое а там другое.
хотя все это всего лишь малая толика разработки, это тысячная доли процента. тебе даже инструкцию написали

ps. добавлю, что последний СДЛ без проблем компилируется любым mingw. Но замечания учту и обновлю инструкцию

SphynX
> hreads" и на всякий случай сам файлик в
> "\win32_mingw\libraries\pthreadVCE2.lib").
> Однако сборка все равно не собиралась, линковщик не находил функцию
> "GetProcessMemoryInfo@12". Исправить можно добавив в CMakeLists в том же самом
> месте новую строчку "psapi". Это подключит нужную библиотеку.

Собрал тоже на codeblocks, на все про все ушло 10 минут, строго по инструкции, единственное как ты заметил правки к cmake понадобилось сделать, в след релиз выкачу их
http://prntscr.com/junqpg

Я честно не понимаю, какие там войны нужны на несколько дней
http://prntscr.com/junrm3