text
Воскресенье, 28 Декабря 2014 16:35

Первый опыт разработки под Android.

Автор
Оцените материал
(1206 голосов)

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

Судьба автора сей писанины не исключение и собственно весь этот манускрипт и посвящен его злоключениям. manus

 

 

Начало долгого пути.

 

Итак, наш главный герой пришел в себя на пороге тусклой комнаты, созерцая в оконце стремительно проваливающееся за горизонт солнце. Обреченно произнеся - "Пора..", он развернулся и, спустившись по жалобно скрипящим ступенькам, уныло побрел к темным зарослям и болотам, именуемой "долиной Гугль".

Вообще странно, что эти чащобы назвали "долиной", в простонародье они снискали славу гиблых и дремучих.

 

koza

Нет заблудиться там сложно, однако, если Вы захотите собрать грибы то вернетесь с арбузом, а если отправитесь туда по ягоды, то вернетесь скорее всего с козой. Лишь абсолютной ночью, когда вы перестаете полагаться на собственное зрение, есть шанс вернуться с тем, за чем вы туда отправлялись. 

 

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

 

Первый взгляд на Cocos2d-x.

 

Выбор пал на кокс (по научному на латыни именуемый алхимиками "Cocos2d-x"), это своего рода переделка популярного под огрызки кокса (те же пресловутые умники окрестили его "Cocos2d"). При первом взгляде аж дыхание перехватывает - поддержка всех возможных платформ вплоть до экзотики в стиле ежевики (на латыни "Blackberry") и  бада-бума (на латыни "Bada").

 

Сам движок представляет из себя что-то в стиле "framework", написанный на C++ и предоставляющий пользователю выбор языка между С\С++, Java и HTML5. Есть и поддержка Lua скриптов.

 

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

 

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

 

 

Каков на вкус Cocos2d-x.

 

Итак, чем же польстился наш главный герой? цветом? вкусом? запахом? возможностями? нет, нет  и еще раз нет. Польстился он как ни странно на возможность разработки на С++.

 

Нет, наш герой вовсе не страдает садомазахизмом, он просто не знает эльфийского языка Java и тем более гномского HTML5, бесплатных движков под Android на могучем русском C# попросту не существует, а выбор движков на C\C++ крайне скудный.

 

gnom Как выяснилось разработчики и пользователи пристрастившиеся к коксу преимущественно эльфы и гномы (кстати большая часть этих славных эльфов и отважных гномов из поднебесной). О чем наглядно говорит релиз среды разработки кокса под Lua и Java скрипт.

 

А вот насчет удобства работы на С++ никто особо и не думает. Под каждую платформу надо компилировать разными компиляторами (а под огрызки так вообще лишь из под мака), а ведь у каждого компилятора и среды свои собственные заморочки, дефы и проблемы. Но ладно фиг с ним - надо так надо, но скакать с одной IDE на другой это уж откровенное издевательство, не говоря уже о том чтобы собирать это все через командную строку.

 

Vs-android в помощь.

 

Терпеть такие лишения наш доблестный герой не был готов и после очередного марафонского полуночного забега в долину "Гугль" вернулся с ответом на вопрос, коим стал "vs-android". Это чудо-проект добавляет в MVS профиль для сборки проектов под Android путем их компиляции при помощи GCC.

 

Установка для новичка не такое уж и простое дело, но после танцев с бубнем мы получаем возможность писать в любимой среде, забыв про возню с Android NDK, SDK и ANT. Теперь при нажатии на заветную F5, мы на выходе получаем заветный *.apk, готовый к работе на вашем или не очень вашем телефоне. bub

 

 

Ну, скажи: «Привет, мир!»

 

Все это замечательно, но дальше поджидают множество проблем со сборкой проекта в студии под кокс. То есть нужно перенастроить его под статичную линковку в наш собственный проект. Очередной забег в "Гугль" не принес никаких результатов, местная фауна и население выпучивало глаза от подобных вопросов. Так что в поисках решения пришлось залезть в самые дебри сборки под Linux и опций компилятора GCC, тем не менее, проблему удалось решить. И вот на экране телефона замаячил HellowWord на коксе.

 

Прелести и кошмары отладки.

 

Честно говоря, герой у нас редкостно ленивая скотина, и каждый раз вручную копировать и ставить приложение на телефон ему лень Но тут на помощь пришла утилита adb из SDK Android'а, что позволяет управлять телефоном подключенным в режиме отладки. Результатом стал батник, что завершает запущенное приложение, удаляет его, копирует новую версию с компа и устанавливает, после чего запускает ее.

 

Естественно для полного счастья необходимы томаты (в смысле "Visual Assist" если кто не понял) и "Visual SVN", но у доблестного автора это дело давно уже ассоциируется с MVS, по этой причине и не будем на этом заострять внимание.  Теперь все было готово к работе, по крайней мере на Android и Windows, а руки уже чесались и рвались в бой, успевши изрядно намаяться со всей от этой возней.

 

Несмотря на все удобства, сборка под Android - дело хлопотное, а отладка так вообще кошмар на улице Грызов. Дело в том, что никакого отладчика для Android не существует в принципе, нет конечно есть парочка но все они являются платными костылями, использование которых в подобном бесплатном проекте как-то не уместно. Так что вместо брекпоинтов пришлось довольствоваться выводом сообщений в лог, благо хоть его с горем пополам можно было получать через упомянутый выше интерфейс adb прямиком на компьютере.

 

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

 

 

Так что, несмотря на все наши труды, работать в основном придется под Окнами (ака "Windows" на латыни), лишь после чего заниматься переносом относительно стабильного и отлаженного под окнами приложения. Забегая вперед признаюсь - автору удалось получить целый пучок багов, проявившихся только под Android. Впрочем, сборка под другим компилятором дело тоже не на 5 копеек и требует приведения синтаксиса к общему знаменателю. Но пока, конечно наш герой всего этого не знал и, пожав плечами, он принялся за Оконную версию.

 

Взгляд из под Windows.

 

И вскоре глаза потихоньку начали лезть на подбородок... Нет мы конечно понимаем движок позиционируется как мобильный, но тем не менее такое пренебрежительного отношение к окнам поражает (ситуация с маками и пингвинами не лучше). okn

 

В нем не оказалось абсолютно никаких средств работы с такими обыденными вещами как клавиатура или вывода собственного лога кокса. Да чего там даже возможность перехода в полноэкранный режим попросту отсутствует. А звуковой движок это вообще настоящий анекдот, если в двух словах, то кокс скрытно запускает стандартный медиа проигрыватель и при воспроизведении звуков \ музыки пихает их этому проигрывателю. Ко всему прочему никаких излишеств, нет даже возможности управления громкостью.

 

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

 

Нашлось место и проблемам совместимости - для работы рендера: требуется поддержка OpenGL 1.5, но некоторые современные дискретные видео карты (например Intel HD Graphics 3000) не поддерживают сей анахронизм, несмотря на поддержку 3 и 4 версии.

 

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

 

Но, тем не менее, кокс выбирают для разработки под мобильные устройства, в данном случае под Android и настольная версия была вторична, да и особо от нее ничего не требовалось так что жить можно было....

 

Cocos2d-x - новые трудности

 

grib

Несмотря на активное развитие коксу, как и любому галлюциногену, свойственны глюки, особенно это касается взаимодействия диспетчеров и менеджера сцен, а вернее их переключения. Конечно, баги есть у всех, но отсутствие проверок внутренней логики собственного API в проекте такого уровня немного поражает. 

 

При разработке движка я опять удивился логике авторов - некоторые тривиальные вещи напрочь отсутствуют в API, типа запись файлов. Наверное в поднебесной не знают про кэш и делают игры без сейвов.

 

Еще небольшой пинок в сторону кокса - необходимость Яво врапера под Android, хотя ни для кого не секрет, что Гугль еще в Android 2.3 (API Level 9) реализовал полноценную поддержку нативного кода, но видать эльфы не позволяют целиком отказаться от Яво костылей. elf

 

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

 

Оптимизация под Андроид.

 

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

Как бы не так, взять к примеру видеопроцессор Qualcomm Adreno 220 (скажем, достаточно хороший вариант для устройств выпущенных в районе 2011 года). Его производительность составляет 2,4 миллиарда пикселей в секунду. Много? Отнюдь, ведь игра должна выдавать 60 FPS, а это значит что на экране 1280х720 за секунду нужно отрисовывать более 55 миллионов пикселей в секунду, лишь для того чтобы вывести одну картину. А ведь поверх нужно рисовать спрайты, интерфейс, текст, иконки и прочую лабуду.

 

Но это еще хороший вариант, но в эпоху второго андройда в бюджетных устройствах обычно применялось что-то вроде Adreno 203 с производительность 0,133 миллиарда пикселей. Конечно, там и разрешение было меньше, но тем не менее, скажем, если в первом случае быстродействия хватит для наложения 44 полноразмерных изображений, то тут лишь на 5 при разрешении 840х480.

 

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

 

Так что если Вы желаете добиться поддержки устройств под управлением Android 2.х, придется напрячься с оптимизацией, рисуя полигоны батчами, а спрайты объединяя в атласы.

 

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

 

Финальная битва.

 

Скоро сказка сказывается, да не скоро дело делается. Но рано или поздно дело все же делается, и вот перед нами готовая игра.

 

boss Все бонусные очки от полученных LEVEL UP'ов герой советует вложить в удачу, она потребуется для финальной битвы с боссом, в роли которого выступает "Google Play". Но одолеть его можно лишь с релизной сборкой, а для того, чтобы ее получить потребуется подписать ее сгенерированным сертификатом, выровнять данные.

 

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

Прочитано 2134 раз Последнее изменение Воскресенье, 28 Декабря 2014 19:36
StaticZ

Game is't a dream, it is the reality, reality which is coming while we dream...

Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript

4 комментарии

  • Комментировать Lekste Воскресенье, 28 Декабря 2014 21:43 написал Lekste

    А не много ли хочет автор? И почему по его мнению, игра под разные платформы должна компилироваться одним компилятором? :)

    Пожаловаться
  • Комментировать StaticZ Вторник, 30 Декабря 2014 04:23 написал StaticZ

    Да хоть десятью - движки на то и существуют, чтобы разработчик мог сосредоточиться на игровой логике а не опускаться в дебри тонкостей сборок и реализации тех или иных возможностей на разных платформах. К тому же автор не говорил, что хочет чтобы все собиралось одним компилятором, он лишь хочет чтобы все собиралось из одной среды (IDE). Любая мало мальски серьезная IDE поддерживает интеграцию сторонних компиляторов, что собственно и использовалось вин версия собиралась компилятором VC, а андройд - компилятором GCC и все это из MS путем простой смены профиля. Но это пришлось уже все самому допиливать ибо авторы не посчитали нужным предоставить хоть какое-то решение облегчающее одновременную разработку под несколько платформ, не говоря уже о том что бы предоставить такую возможность самим (а ведь они даже дошли до того что написали свою IDE для движка). А ведь компиляция бинарника лишь 1й шаг для сборки *.apk, что можно будет установить на устройство. Некоторые коммерческие движки к примеру организуют компиляцию под любые платформы на облачных серверах, так что можно получать бинарники под маки сидя на винде\пингвине. Я конечно не любитель подобного подхода, но по крайней мере упростить задачу кроссплатформенной сборки под то что возможно нужно было бы. В конце концов это в интересах самих разработчиков, поскольку специально возиться с сборками под всякие бады и блекбери мало кто хочет, большинство игр вообще делают лишь на одной платформе. В результате одна из ключевых особенностей движка - огромное число поддерживаемых платформ, остается не используемой.

    Пожаловаться
  • Комментировать Lekste Среда, 31 Декабря 2014 04:47 написал Lekste

    Наверно потому что производители различных устройств не заинтересованы, а иногда и намеренно препятствуют развитию конкурентов.

    Например, производитель огрызков не предоставляет компилятора ни под какую платформу, кроме MacOS, а microsoft до недавнего времени, из SDK имела лишь версию для C# и скудную документацию с описанием диаграммы потоков.

    Сборка на облачных сервисах? Потому они и платные, что требуют доп. Затрат.

    Самим настроить все под одну среду?
    VS существует лишь под Windows.
    А как же любители Других ОС?
    А как же любители других IDE?
    А как же те, кто не хочет пиратить и не хочет платить за лицензию студии?

    Берешь любимую IDE и настраиваешь - идеальный выход.

    Нет средств работы с клавиатурой и т д?
    А как же джаваподобная система с Слушателями ивентов?

    Нельзя даже регулировать звук?
    Тут я не проверял, но согласно доке, есть метод setBackgroundSoundVolume и setSoundEffectVolume

    Запись файлов?
    Двиг. узконаправленный и то, каким образом ты что-то сохраняешь или передаешь во внешнюю систему его касаться не должно.

    Отказаться от Ява-врапперов и заставить толпы людей убиться обо что нибудь, когда они захотят сделать шаринг в соцсети, прицепить какую-нибудь рекламу за монетки, попытаться вытянуть новости с какого-нибудь новостного сервиса, а потом обнаружат, что все SDK заточенные под Андроид на Java? :)

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

    Насчет буферизации не совсем понял, что имелось ввиду, но есть же SpriteManager.

    Насчет версии OpenGL, оф сайт еще осенью прошлого года говорил, что требуется OpenGL 2.1.
    Странно, что он 1.5 просит.

    Пожаловаться
  • Комментировать StaticZ Среда, 31 Декабря 2014 23:18 написал StaticZ

    MacOS, как и все огрызки вообще явление крайне скотское и странное. Посути контора и ее продукция уже давно абсолютно ничего из себя не представляет, кроме распиаренного до вселенских размеров лейбла....


    > Самим настроить все под одну среду?
    > VS существует лишь под Windows.
    > А как же любители Других ОС?
    > А как же любители других IDE?

    Ну во первых VS и винда самые распространенные и главное являющиеся по сути общепринятым стандартом, а во вторых ну хоть под что-то сделали бы, в конце концов есть вайн и виртуалки, да и если уж такое дело можно заставить себя писать в другой ОС\IDE...


    > Нет средств работы с клавиатурой и т д?
    > А как же джаваподобная система с Слушателями ивентов?

    Чего-чего? В API нет ровным счетом ничего про это. Да и с какого заставлять разработчиков ломать голову и лепить костыли? Любой движок прежде всего должен избавлять разработчика от возни с устройствами ввода\вывода. К тому же движок рассчитан все же на казульные игры и ради этого заставлять тянуть за собой не очень то популярную на настолках яву не очень то красиво.


    > Тут я не проверял, но согласно доке, есть метод setBackgroundSoundVolume и setSoundEffectVolume

    Есть, только в Win версии это все не реализованно, а под линуксами и маками возможно и сам звук не работает. Кроме того если память не изменяет то в вин версии музыка и звуки работают только в wav формате, что приводит к неслабому раздутию ресурсов.


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

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


    > Отказаться от Ява-врапперов и заставить толпы людей убиться обо что нибудь, когда
    > они захотят сделать шаринг в соцсети, прицепить какую-нибудь рекламу за монетки,
    > попытаться вытянуть новости с какого-нибудь новостного сервиса, а потом
    > обнаружат, что все SDK заточенные под Андроид на Java? :)

    Есть официальный врапер на С++ для вызова из неуправляемого кода ява методов и объектов. Причем он используется самим коксом. Для этого вовсе не обязательно делать врапер на эльфийском для всего приложения.


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

    Кто ограничивает? Половина систем корнями уходят в линух, начиная от андройда заканчивая тем же МакОсом. Для того же андройда прекрасно работает счетчик используемой памяти и загрузки CPU, что и в линухе. А для чего нужно? Во первых следить за утечками памяти, во вторых выявлять проблемные места в логике приложения. Вообще подобные возможности есть в любом API приличной ОС.


    > Насчет версии OpenGL, оф сайт еще осенью прошлого года говорил, что требуется
    > OpenGL 2.1.
    > Странно, что он 1.5 просит.

    На некоторых системах с дискретным видео, таких как например "Intel HD Graphics 3000" при запуске выдается сообщение о необходимости обновить драйвер OpenGL с версии 1.1 до 1.5. Проблема заключается в том что некоторые производители дискретных карт экономят на поддержке старых версиях OpenGL, так Intel HD3000 не поддерживает OpenGL версии между 1.1 и 3.0. Честно говоря мне DirectX нравиться куда больше из-за своей лаконичности - есть версия интерфейса и она либо поддерживается видео картой либо нет. С OpenGL ситуация достаточно мутная, т.к. он состоит из кучи отдельных расширений, что прыгают по разным версиям, а набор поддерживаемых расширений у всех карт различается без каких либо внятных закономерностей. Насколько я понимаю кокос запрашивает какие-то расширения под версию 1.5, другие под версию 2.1, поэтому да минимальные требования это 2.1...

    Пожаловаться
Авторизуйтесь, чтобы получить возможность оставлять комментарии

Панель входа

Добро пожаловать!

Заходите. Чувствуйте себя как дома.

Мы в контакте

Опрос о статьях на сайте.

Какие статьи вам наиболее интересны?
 

Это из галереи!

  • KittyScrin_7

Я выложила отчет с фотографиями о том, как я побывала на DevGAMM в этом году!

А знаете ли вы...

ste2

полузаброшенный сайтkn1kn4kn5Плагины для RPG MakerДневник одной нэкоkn Топ Разработка игр