LG.BALUKATION's Weblog

Ничего, это тоже кое-что… А при желании из него можно сделать что угодно

minimal cocos hello

Posted by LG.BALUKATION на 2013/03/17

Уже какое-то время я стал поглядывать на Cocos2d-x. Я ничего толком не знал об этом движке, но слышал много лестного о его «яблочном» собрате и решил посмотреть — что же за кокос такой. Замутил приватный форк, стал почитывать исходники на выходных, компилять примеры и читать обучающие статьи…

В книге про Cococs2d-x более-менее подробно расписывается шаблон игры для iOS и нечто подобное я рассчитывал получить в Windows. Но нет, не получил — пришлось делать самому.

Чем это отличается об обычного варианта, который доступен на iOS не из шаблона и на всех остальных системах? Просто мне показалось излишним для мелких проектов таскать все фичи Кокоса (физику, скрипты, …) — хочется иметь доступ к движку без нагромождения всяких дополнительных фич. Плюс хотелось избавится от динамической линковки, что было достигнуто лишь частично. Мне кажется проект тут не настолько большой, что бы разбивать его на библиотеки и иметь с этого какое-нить существенное удобство — такие мелкие штуки вполне приемлимо сливать в один бинарник.

Итак, для начала я просто скопировал сам cocos2dx (основа движка — без звука, физики, скриптов и т. п.) и hellocpp (тестовый пример) в отдельный репозиторий. Затем создал пустые солюшен и проект в студии и сохранил в том же репозитории.

Однако, простым добавлением файлов из проектов движка и примера дело не ограничилось. Ведь пустой проект совсем пустой, так что нужно прописать ещё кое-какие дефайны, пути, библиотеки и маленький скрипт для удобства.

Сперва я подумал добавить в пути поиска заголовков только корни движка и проекта, но это оказалось не лучшее решение. Основным препятствием стали библиотеки, поставляемые вместе с Кокосом — их заголовки запрятаны в недра движка, при этом используются они как не запрятанные. Можно конечно вытащить их из движка наружу (это было бы ближе к идеальному случаю), но я не стал с этим возится и прописал пути вроде тех, что были в проекте движка и примера:

$(ProjectDir)Cocos2Dx;
$(ProjectDir)Cocos2Dx\include;
$(ProjectDir)Cocos2Dx\kazmath\include;
$(ProjectDir)Cocos2Dx\platform\win32;
$(ProjectDir)Cocos2Dx\platform\third_party\win32\iconv;
$(ProjectDir)Cocos2Dx\platform\third_party\win32\libjpeg;
$(ProjectDir)Cocos2Dx\platform\third_party\win32\libpng;
$(ProjectDir)Cocos2Dx\platform\third_party\win32\libtiff;
$(ProjectDir)Cocos2Dx\platform\third_party\win32\libxml2;
$(ProjectDir)Cocos2Dx\platform\third_party\win32\OGLES;
$(ProjectDir)Cocos2Dx\platform\third_party\win32\pthread;
$(ProjectDir)Cocos2Dx\platform\third_party\win32\zlib;
$(ProjectDir)HelloCpp\Classes;
$(ProjectDir)HelloCpp\proj.win32;
$(IncludePath)

Дефайны Кокос использует как в обычном оконном приложении (так что наверное есть смысл создавать проект такого типа, а не пустой), плюс несколько своих. Их я тоже взял из оригинальных проектов.

Отладочная версия:

_CRT_SECURE_NO_WARNINGS;
_DEBUG;
_SCL_SECURE_NO_WARNINGS;
_WINDOWS;
COCOS2D_DEBUG=1;
GL_GLEXT_PROTOTYPES;
WIN32;

Релиз:

_CRT_SECURE_NO_WARNINGS;
_SCL_SECURE_NO_WARNINGS;
_WINDOWS;
GL_GLEXT_PROTOTYPES;
NDEBUG;
WIN32;

Тут важный нюанс, что в оригинале Кокос проверяет наличие дефайна _USRDLL (объявлен в сборке движка) и соответственно генерирует экспорт и импорт библиотечных символов. Поскольку одна из затей проекта состоит в использовании Кокоса напрямую, а не библиотекой — нужно не добавлять этот дефайн и убрать вообще информацию о символах библиотеки. В файле Cocos2Dx/platform/win32/CCPlatformDefine.h
заменить

#if defined(_USRDLL)
#define CC_DLL __declspec(dllexport)
#else /* use a DLL library */
#define CC_DLL __declspec(dllimport)
#endif

на

#define CC_DLL

Последний нюанс, мешающий компиляции — внезапная проблема со строками. Что бы их избежать, нужно в настройках проекта сказать использовать набор символов Unicode (по-умолчанию там MultiByte).

Вместе с движком поставляется несколько бинарных библиотек. В идеале их так же можно собирать из исходников (благо все они опенсорсные), но пока можно линковаться с готовыми — сам Кокос так и делает. Хранятся в данном случае библиотеки в каталоге $(ProjectDir)Cocos2Dx\platform\third_party\win32\libraries

Вот перечень нужных:

glew32.lib;
libiconv.lib;
libjpeg.lib;
libpng.lib;
libtiff.lib;
libxml2.lib;
libzlib.lib;
opengl32.lib;
pthreadVCE2.lib;

Как видите, это обычные библиотеки для загрузки изображений в различных форматах, системная библиотека OpenGL (она идёт внутри Windows Platform SDK, которое ставится при установке Visual C++) и библиотеки принятые в Unix для работы с потоками, кодировками и xml.

В этот момент уже должен создаваться исполняемый файл, но он пока не работает. Поскольку я не стал заморачиваться со сборкой сторонних библиотек, а взял готовые — нужно скопировать их к приложению. Ещё было бы здорово скопировать к приложению ресурсы — ведь оно рассчитывает найти и показать всякие там картинки и т п. Для этого действа полезно назначить событие после сборки примерно такого содержания:

if not exist «$(LocalDebuggerWorkingDirectory)» mkdir «$(LocalDebuggerWorkingDirectory)»
xcopy /Y /Q «$(ProjectDir)Cocos2Dx\platform\third_party\win32\libraries\*.dll» «$(LocalDebuggerWorkingDirectory)»
xcopy /S /Y /Q «$(ProjectDir)HelloCpp\Resources\*» «$(LocalDebuggerWorkingDirectory)»

Про LocalDebuggerWorkingDirectory — я переопределил расположение и название выходного файла линкера, что бы он не валялся где-то в куче по-сути временных объектных файлов, а жил в своей уютной директории. Естественно, эта же директория является рабочей и для отладчика.

Теперь проект должен собираться и запускаться, отмечу лишь пару мелочей напоследок. Проекты, поставляемые вместе с Кокосом и стандартные настройки проекта не очень рассчитаны на использование современных многоядерных процессоров. В форкнутом мной Кокосе нормально не использовалась ни параллельная сборка нескольких проектов, ни параллельная сборка нескольких файлов внутри одного проекта при отладке (только при релизе). Я во всех случаях включил Multi Processor Compilation и выключил препятствующие ему Minimal Rebuild, Incremental Link, Debug Information Format отличный от Program Database (т. е. всякие Edit and Continue лишь замедляют сборку).

Полученный в Visual C++ 2010 Express и Cocos2d-x 2.0.4 проект можно посмотреть тут https://bitbucket.org/lgb/minimal_cocos_hello

Реклама

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s