Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 104
Так что если вы выпустите под андроид APK, в котором все (или часть) текстур будет пожата в PVR, как бы вы это сделали для iOS, — то столкнетесь с крашами на куче устройств
С вот такой строчкой в манифесте?
<supports-gl-texture android:name="GL_IMG_texture_compression_pvrtc" />
Так а при чем тут манифест? Если хардварно PVR не поддерживается, девайсина будет пытаться при загрузке распаковать ее в 32bpp. И может тупо скрашиться по памяти.
А, ну запретить людям без PowerVR чипа видеть игру в гугл плее — это понятно. Речь-то не о том, чтобы запретить. Речь о том, чтобы запуститься.
Лучше уж приложение будет недоступно, чем пользователь поставит 1 звездочку и напишет, что у него, видите ли, не запускается.
Вы же сами написали, что нужно делать :) А то эдак можно возмущаться, что и GLES2 не у всех окажется. Юзаете фичу — ставите флаг в манифесте, по-моему достаточно честно :)
Но вообще android в этом плане ужасен, да. Я бы еще ввел фильтр по стоимости устройства, чтобы отсеять всякие дешевки :)
Вы же сами написали, что нужно делать :) А то эдак можно возмущаться, что и GLES2 не у всех окажется. Юзаете фичу — ставите флаг в манифесте, по-моему достаточно честно :)
Но вообще android в этом плане ужасен, да. Я бы еще ввел фильтр по стоимости устройства, чтобы отсеять всякие дешевки :)
Обычно дешевки можно отфильтровать по размеру экрана.
Кстати, удивительно, сколько же людей с телефонами 320х240 начинают ныть, что, мол, разработчики — идиоты и не могут сделать игру для их 100-долларового телефона.
Кстати, удивительно, сколько же людей с телефонами 320х240 начинают ныть, что, мол, разработчики — идиоты и не могут сделать игру для их 100-долларового телефона.
Согласен. В проекте, который вот-вот выпустим я выкинул это разрешение, от греха подальше. Действительно слишком много неадекватных пользователей, которых легче отсеять, чем надеяться на понимание с их стороны.
Ага, и нытьё ARM v6-юзеров тож доставляет. Слава ARM'у, скоро это старое говнище все забудут и перейдут на v7 Cortex A5/A7.
Мы, кстати, сначала тоже сделали ARM v7 only, но потом-таки скопмилили под 6. Ибо парк устройств еще довольно велик, и отсекать нельзя.
Чуваки, как-то гадостно читать ваше обсуждение пользователей, написанное в таком тоне.
Мало ли у кого какое говнище. Может, ещё обсудите, кто как одет не по моде?
Поставили фильтры — и ок. Не поставили — не показывайте пальцем.
Мало ли у кого какое говнище. Может, ещё обсудите, кто как одет не по моде?
Поставили фильтры — и ок. Не поставили — не показывайте пальцем.
Иногда просто не так просто отфильтровать. Есть адские говнодевайсы с довольно большими экранами. А некоторые пользователи просто вообще неадекватно воспринимают отказ игры запускаться на их девайсине за $100. Кричат, ругаются, ставят единички и брызжут слюной.
Ну так ругайте неадекватных пользователей, а не их девайсы.
Одни и те же девайсы могут быть и у адекватных, и у неадекватных пользователей.
Это всё равно, что писать: «Чуваки, жигули — полное говнище, а кто их купил — лохи!» на форуме, где у половины — жигули. Мало ли по какой причине были куплены именно жигули?
Одни и те же девайсы могут быть и у адекватных, и у неадекватных пользователей.
Это всё равно, что писать: «Чуваки, жигули — полное говнище, а кто их купил — лохи!» на форуме, где у половины — жигули. Мало ли по какой причине были куплены именно жигули?
Проблема в том, что, увидив приложение в обзоре, дайджесте, на форуме или ещё где юзеры ищут в маркете его, а если не находят (оно скрыто, т.к. не проходит по манифесту), начинается вонь на форумах, в комментах и прочих местах — мол, разработчик такой и сякой, на мой телефон за 100 баксов с процссором от калькулятора и экраном из 2005 года не хочет портировать Крайсис. А на ответы «купи нормальный девайс, на котором можно будет нормально реализовать функционал — получи игры» начинается «а вот то работает, а вот у этих всё хорошо, а вот здесь всё идет, и вообще, разработчик — ты мудак, получи свой (+ _ _ _ _) рейтинг и гневную парашу в комментах».
Почему-то покупатели дешёвых, кривых, китайских и прочих смартфонов, не отличающихся ни популярным железом, ни актуальной ОС, ни нормальным количеством памяти и разрешением экрана считают, что им все должны, а на ответы «аппаратно не реализуемо» приходят в ярость и начинают гадить. Это вам не гадостно?
Почему-то покупатели дешёвых, кривых, китайских и прочих смартфонов, не отличающихся ни популярным железом, ни актуальной ОС, ни нормальным количеством памяти и разрешением экрана считают, что им все должны, а на ответы «аппаратно не реализуемо» приходят в ярость и начинают гадить. Это вам не гадостно?
Логика, думаю, такая — если «Angry Birds» идет, значит все должно пойти. =)
К слову, тот же Angry Birds Space ещё некоторое время назад адски глючило и таращило в плане текстур на референсном Galaxy Nexus. Одна из самых востребованных и популярных игр, блин…
У вас приложение круче «Angry Birds»?
Тяжелее
Тяжелее в плане? Сложнее шейдеры, 3Д графика? Т.е. чем приложение выгодно отличается перед теми же «Angry Birds» с точки зрения пользователя, чтобы оправдать требование более мощного железа?
У вас какие-то неправильные вопросы. Что значит «чем выгодно отличается для пользователя»?
У нас гораздо больше графики. Но кому-то птички все равно нравятся больше. А кому-то — крестики-нолики без графики вообще.
Да, ссылку на игрушку я здесь в комментах уже давал.
У нас гораздо больше графики. Но кому-то птички все равно нравятся больше. А кому-то — крестики-нолики без графики вообще.
Да, ссылку на игрушку я здесь в комментах уже давал.
Что значит «чем выгодно отличается для пользователя»?Можно переформулировать, что существуют приложения с аналогичным количеством графики, которые работают.
Это общая проблема из-за сильной дифференцированности платформы или, например, следствие выбора инструмента, который ограничивает? Вы в статье на Unity жалуетесь.
Я это понимаю, и это мне тоже гадостно.
Но почему вы хотите походить на этих пользователей?
Собственно, меня напрягли исключительно необычные для хабра термины типа «говнище», «вонь». Если бы не они, я бы особо и не обратил внимания, обычные дела.
Понимаете, у всех разработчиков свои похожие сложности, не только у разработчиков под андроид. Обсуждения особенностей браузеров встречаются каждый день, но я ни разу не видел, чтобы кто-то говорил про IE вашими выражениями.
Но почему вы хотите походить на этих пользователей?
Собственно, меня напрягли исключительно необычные для хабра термины типа «говнище», «вонь». Если бы не они, я бы особо и не обратил внимания, обычные дела.
Понимаете, у всех разработчиков свои похожие сложности, не только у разработчиков под андроид. Обсуждения особенностей браузеров встречаются каждый день, но я ни разу не видел, чтобы кто-то говорил про IE вашими выражениями.
«Говнище» — погорячился. Вонь на форумах — ну простите, это именно то, что там происходит. Со всеми вытекающими. Впрочем, что-то я действительно излишне экспрессивен. Прошу простить, если задел ваше чувство прекрасного.
Обсуждения особенностей браузеров встречаются каждый день, но я ни разу не видел, чтобы кто-то говорил про IE вашими выражениями.
Шутите так?)
С IE есть надежда, т.к постепенно он совершенствуется и на данный момент очень даже не плох. А эти девайсы, улучшить уже вряд ли получиться и что самое ужасное их число скорее всего только будет расти. Это как если на IE6 становился все более и более популярным.
А так бывает гадостно читать их отзывы. Особенно для бесплатного приложения и без рекламы. Но самое обидное, что ответить никак не можешь (конечно, можно поискать на гугл+, спросить и т.д).
Например, игра работает совершенно нормально. Но если ее свернуть, а потом вернуться в нее — то половина текстур заменяется черными квадратами. Что это? Баг Unity?
это нехватка памяти
больше похоже на stackoverflow.com/questions/12508769/libgdx-app-exit-on-android-not-closing-application, нет?
Я сомневаюсь, что разработчики Unity не знают, что на андроиде нужно восстанавливать ресурсы после потери контекста :)
Может просто текстуры не перегружаются?
Ну тоесть при сворачивании тебе ни кто не гарантирует что контектс не потеряет данные текстур.
Посему не плохо бы их перегрузить.
Может в юнити бок какой, что он не все перегружает?
(я больше по мармеладу ориентируюсь)
Ну тоесть при сворачивании тебе ни кто не гарантирует что контектс не потеряет данные текстур.
Посему не плохо бы их перегрузить.
Может в юнити бок какой, что он не все перегружает?
(я больше по мармеладу ориентируюсь)
Но если ее свернуть, а потом вернуться в нее — то половина текстур заменяется черными квадратами.
Это встречается сплошь и рядом в играх под андроид (из последних вспомню Rayman Origins). Связано с тем, что андроид не гарантирует, что OpenGL ресурсы сохранятся в памяти при работающей в фоне активити. Фиксится довольно просто — при возвращении из фона текстуры перезагружаются. Игры пишу на своем движке, реализовывал это сам — там пару строк кода всего.
Что это? Баг Unity?
Однозначно. Это известная «фича» андроида и странно, что в юнити это не исправили.
Спасибо за инфу. Мда… вариант перезагружать все текстуры после возврата из фона — как-то не очень радует.
Правда, появилась идея — после возврата из фона проверять все текстуры на «черноту» и перезагружать только черные.
Но это прокатит для тех текстур, что мы загрузили сами, руками (атласы). А вот те, что загрузила сама Unity (например, текстуры партиклов) — тут уж контролю не поддаются.
Правда, появилась идея — после возврата из фона проверять все текстуры на «черноту» и перезагружать только черные.
Но это прокатит для тех текстур, что мы загрузили сами, руками (атласы). А вот те, что загрузила сама Unity (например, текстуры партиклов) — тут уж контролю не поддаются.
Принудительно свопать OpenGL память не получится?
Когда вы пишите на Unity, вы ничего не знаете ни о каком OpenGL.
Ну вообще-то это не совсем верно. Доступ можно получить (более того, с помощью маршаллинга вполне уютно можно писать на плюсах).
Другая проблема заключается в том, что не всегда успеваешь сохранить ссылки на текстуры при паузе приложения — activity сбрасывает текстуры раньше, чем успеваешь их куда-либо записать.
Другая проблема заключается в том, что не всегда успеваешь сохранить ссылки на текстуры при паузе приложения — activity сбрасывает текстуры раньше, чем успеваешь их куда-либо записать.
Как бы не только на Androidе потеря контекста приводит к невалидности текстур. PC тоже так может :) Странно, что вы об этом раньше не знали.
Дело не в том, что я раньше не знал (я про PC знаю).
Дело в том, что при написании на Unity — заботиться об этом явно должна либо сама Unity, либо Android. Не знаю, кто об этом думает по iOS — но там такого нет.
И я говорю про то, что это не должно быть моей заботой по одной простой причине — при написании на Юнити у вас просто нет над такими штуками контроля. На то это и высокоуровневая среда разработки.
Дело в том, что при написании на Unity — заботиться об этом явно должна либо сама Unity, либо Android. Не знаю, кто об этом думает по iOS — но там такого нет.
И я говорю про то, что это не должно быть моей заботой по одной простой причине — при написании на Юнити у вас просто нет над такими штуками контроля. На то это и высокоуровневая среда разработки.
А в чем проблема подгружать нужные текстуры при первом запуске? Нет, меня это правда интересует.
1. для Mali подгружать, грубо говоря, — нечего
2. подгружать — не проблема. но вот поддерживать пайплайн интеграции арта — проблема. у нас сейчас около 10 атласов с GUI и всякими игровыми спрайтами. когда нужно что-то изменить/добавить — то придется перепаковывать не 1 атлас, а сразу несколько, в разных вариантах.
а так, глобально, — конечно же, никакой великой проблемы нет. просто, адски неудобно.
2. подгружать — не проблема. но вот поддерживать пайплайн интеграции арта — проблема. у нас сейчас около 10 атласов с GUI и всякими игровыми спрайтами. когда нужно что-то изменить/добавить — то придется перепаковывать не 1 атлас, а сразу несколько, в разных вариантах.
а так, глобально, — конечно же, никакой великой проблемы нет. просто, адски неудобно.
Мы атласы генерим в png, а потом уже при тестах, близких к финальным, конвертим в всякие сочетания форматов сжатия и размеров экранов (зачем пользователю с экраном 800x480, тянуть gui от 1920 к примеру).
Ну и всё это закидывается на сервер, при старте игра определяет что ей нужно и вытягивает пак для данного девайса.
Правда скачка кэша может негативно сказатся на отзывах — у кого-то инет не очень, не смог выкачать, обиделся и т.п.
Поэтому для маленьких экранов, и стараемся всё запихать в apk, а делать докачку ресов только уже для совсем больших экранов.
Ну и всё это закидывается на сервер, при старте игра определяет что ей нужно и вытягивает пак для данного девайса.
Правда скачка кэша может негативно сказатся на отзывах — у кого-то инет не очень, не смог выкачать, обиделся и т.п.
Поэтому для маленьких экранов, и стараемся всё запихать в apk, а делать докачку ресов только уже для совсем больших экранов.
Пару дней назад такую же картинку вставлял :)
habrahabr.ru/post/169695/
habrahabr.ru/post/169695/
В своём движке, относительно текстур руководствуюсь следующими правилами:
— все текстуры 2^N
— стараться избегать размеров > 1024 (время выборки)
— стараться жать текстуры с выносом альфа-канала (если имеется) в отдельную текстуру A8 (память, время выборки)
— win, mac, nix = DXT1
— ios = PVRTC
— android = ETC (даже не смотря на то, что Tegra лучше дружит с DXT)
— для любых других текстур использовать RGBA8, A8
— все сжатые текстуры квадратные
— конвертация происходит в момент сборки пака, под конкретную ось
— перезагружать текстуры и рендер-таргеты при потере контекста
Cо стилусом проблем небыло, обрабатывается как и любой другой тач.
— все текстуры 2^N
— стараться избегать размеров > 1024 (время выборки)
— стараться жать текстуры с выносом альфа-канала (если имеется) в отдельную текстуру A8 (память, время выборки)
— win, mac, nix = DXT1
— ios = PVRTC
— android = ETC (даже не смотря на то, что Tegra лучше дружит с DXT)
— для любых других текстур использовать RGBA8, A8
— все сжатые текстуры квадратные
— конвертация происходит в момент сборки пака, под конкретную ось
— перезагружать текстуры и рендер-таргеты при потере контекста
Cо стилусом проблем небыло, обрабатывается как и любой другой тач.
Ну, тут все зависит от игры, конечно…
Для нас, например, атласы 1х1к — неприемлемы, т.к. адски увеличат кол-во draw calls по сравнению с 2х2к. Да и жать альфу отдельной текстурой и клеить шейдером — та еще морока + потеря производительности.
Для нас, например, атласы 1х1к — неприемлемы, т.к. адски увеличат кол-во draw calls по сравнению с 2х2к. Да и жать альфу отдельной текстурой и клеить шейдером — та еще морока + потеря производительности.
батчинг никто не отменял. или у вас free версия Unity3d?
Батчинг — он работает если спрайты делят один материал (атлас). Два спрайта использующие разные текстуры, в один дро колл не сбатчатся.
docs.unity3d.com/Documentation/Manual/DrawCallBatching.html
docs.unity3d.com/Documentation/Manual/DrawCallBatching.html
Only objects sharing the same material can be batched together.…
Unity can automatically batch moving objects into the same draw call if they share the same material.
Раскройте, пожалуйста, тему мороки и потери производительности, ибо не могу разглядеть там ни первого, ни второго. Может, от недостатка опыта.
Генератор атласов на выходе генерит PNG или PVR. Сгенерить RGB в одну PNG, а альфу — в другую — нужно отдельной тулзятиной. Это раз.
Во-вторых — шейдер далее должен работать уже не с одной текстурой, а с двумя. И переставлять их тоже обе.
Во-вторых — шейдер далее должен работать уже не с одной текстурой, а с двумя. И переставлять их тоже обе.
Разодрать PNG/ARGB на PNG/RGB + PNG/A можно с помощью imagemagick, bash и получаса времени. Для PVR и прочих вариантов компрессии тоже есть консольные утилиты, тривиально встраиваемые в скрипты сборки ассетов.
Проблемы с двумя текстурами в шейдерах я тоже не вижу — два раза написать sampler2D и texture2D вместо одного. Ну, и переставлять две (четыре, восемьдесят три) текстуры в материале должно быть не принципиально сложнее, чем одну. По крайней мере в голом OpenGL, не знаю, как там с этим в юнити.
Проблемы с двумя текстурами в шейдерах я тоже не вижу — два раза написать sampler2D и texture2D вместо одного. Ну, и переставлять две (четыре, восемьдесят три) текстуры в материале должно быть не принципиально сложнее, чем одну. По крайней мере в голом OpenGL, не знаю, как там с этим в юнити.
Ну, у нас тут еще движок есть, который работает с одной текстурой.
То, что вы описали — да, ок. Я не говорил, что задача нерешаема. Я говорил, что это изрядно усложняет пайплайн. Когда у вас 10 атласов и проект находится в режиме постоянного развития, постоянно добавляются новые спрайты, картинки и т.п. — каждый раз проделывать все эти махинации с атласами — не очень-то весело.
То, что вы описали — да, ок. Я не говорил, что задача нерешаема. Я говорил, что это изрядно усложняет пайплайн. Когда у вас 10 атласов и проект находится в режиме постоянного развития, постоянно добавляются новые спрайты, картинки и т.п. — каждый раз проделывать все эти махинации с атласами — не очень-то весело.
Стоп, стоп, стоп. А на что Вы жалуетесь??? Вы занялись разработкой под бесплатную ОС (уже на этом шаге Вам НИКТО НЕ ДОЛЖЕН НИЧЕГО), которая не контролирует выполнение производителями аппаратных требований и вынуждает их делать свою оболочку, потому как родная тормозит адски. Она бесплатна — скажите спасибо, что она вообще работает.
«В своём движке, относительно текстур руководствуюсь следующими правилами:
— все текстуры 2^N
— стараться избегать размеров > 1024 (время выборки)
…
…
…
Cо стилусом проблем небыло, обрабатывается как и любой другой тач.»
Аналогично в наших проектах.
— все текстуры 2^N
— стараться избегать размеров > 1024 (время выборки)
…
…
…
Cо стилусом проблем небыло, обрабатывается как и любой другой тач.»
Аналогично в наших проектах.
Сколько текстурных атласов 2k*2k у вас в памяти одномоментно?
Навскидку — около 10.
Ого. А саму игру глянуть можно?
А для 2Д графики сами писали двиг или использовали что-то?
Юзали ex2D: www.ex-dev.com/ex2d/
Судя по этой картинке 
ex2D не умеет вырезать прозрачные области у спрайтов на атласе (они там розовым обозначены если я правильно понял). Понятно, что менять ex2Dна что-то другое уже поздно, проект написан, но может добавить такой функционал, чтобы убирать эти области, это позволит несколько плотнее использовать атласы (насколько — уже зависит от проекта и артов).
ex2D не умеет вырезать прозрачные области у спрайтов на атласе (они там розовым обозначены если я правильно понял). Понятно, что менять ex2Dна что-то другое уже поздно, проект написан, но может добавить такой функционал, чтобы убирать эти области, это позволит несколько плотнее использовать атласы (насколько — уже зависит от проекта и артов).
Спасибо, интересно было почитать ;)
Вот тут только поправьте — у Note второй touch сенсор — индуктивный, а не резистивный. (Большая разница, стилусом можно рисовать вообще не касаясь экрана, если заклеить на нем кнопку скотчем например).
а второй — для стилуса (резистивный)
Вот тут только поправьте — у Note второй touch сенсор — индуктивный, а не резистивный. (Большая разница, стилусом можно рисовать вообще не касаясь экрана, если заклеить на нем кнопку скотчем например).
Кстати, кто знает как с этим дело на Windows Phone?
Короче говоря, статья не про то, что «палки в колеса от Android», а больше про баги Unity и про то, что нужно читать мануалы и спецификации платформы, под которую разрабатываешь. А если не читаешь, то самого себя посыпать пеплом.
Как раз вчера собрал первый билд игры под Андроид, разрабатывал и тестил до этого исключительно под iOS.
Пришлось переписать немного код под «резиновость» для разных экранов, а так билд сходу заработал на телефоне с MTK 6577 и PowerVR видео и на планшете с видео от Mali. Никаких хитрых телодвижений по перепаковке текстур я не делал, просто сбилдил то что было от iOS.
Так вот что то меня ваша статья немного запутала, текстуры у меня по наследию от iOS были попакованы в PVR, но игра абсолютно нормально запустилась на Mali и ничего не вылетело, но судя по вашей статье должно было, или я вас не так понял?
Ещё и размер билда получился в два раза меньше чем под iOS.
Пришлось переписать немного код под «резиновость» для разных экранов, а так билд сходу заработал на телефоне с MTK 6577 и PowerVR видео и на планшете с видео от Mali. Никаких хитрых телодвижений по перепаковке текстур я не делал, просто сбилдил то что было от iOS.
Так вот что то меня ваша статья немного запутала, текстуры у меня по наследию от iOS были попакованы в PVR, но игра абсолютно нормально запустилась на Mali и ничего не вылетело, но судя по вашей статье должно было, или я вас не так понял?
Ещё и размер билда получился в два раза меньше чем под iOS.
Только предварительно жать все текстуры в разные форматы, индивидуально для каждого GPU и потом либо делать несколько приложение в Google Play
Вовсе не обязательно делать несколько приложений.
developer.android.com/google/play/publishing/multiple-apks.html
Будущее за HTML5,6,…
Скоро мы забудем об этих проблемах…
Переход направления разработки приложений в WebApps «не за горами»…
Зашел на веб-ресурс и стал пользоваться. Нажал «установить» и оно скачивается на «диск» и пользуешься им в любой момент без подключения к интернету, загружая так же с ярлычка (как и сейчас установленное нативное).
Жду не дождусь полноценной поддержки и запуска HTML5-приложений напрямую из ОС (без пожирающих ресурсы прослоек и надстроек) и всеми устройствами.
http://www.w3.org/TR/offline-webapps
Скоро мы забудем об этих проблемах…
Переход направления разработки приложений в WebApps «не за горами»…
Зашел на веб-ресурс и стал пользоваться. Нажал «установить» и оно скачивается на «диск» и пользуешься им в любой момент без подключения к интернету, загружая так же с ярлычка (как и сейчас установленное нативное).
Жду не дождусь полноценной поддержки и запуска HTML5-приложений напрямую из ОС (без пожирающих ресурсы прослоек и надстроек) и всеми устройствами.
http://www.w3.org/TR/offline-webapps
>HTML5-приложения (без пожирающих ресурсы прослоек и надстроек)
взаимоисключающие вещи
взаимоисключающие вещи
Можно минусовать, однако компания Intel уже активно начала продвижение в этом направлении: читаем здесь.
А может кто-то считает, что Intel тоже не права???
И они не далекого ума, как и мы с Sega100500?
)))))))))))))
А может кто-то считает, что Intel тоже не права???
И они не далекого ума, как и мы с Sega100500?
)))))))))))))
Да-да-да, я уже осознаю, что кинул камушек не в тот огород — здесь горло перегрызут за натив ))) А про Intel уже читал в статьях еще до этой публикации. И не только Intel, кстати.
Ладно, улетать в минуса, так уж с музыкой :-)
Будущее мобильных приложений — нативные или HTML
Ладно, улетать в минуса, так уж с музыкой :-)
Будущее мобильных приложений — нативные или HTML
Спасибо, Sega100500!
Зачетная статья!!!
Я двумя руками «ЗА» и согласен с ней!
Разработчики нативов, поймите: вы — практически бесплатные рабы для гигантов IT-индустрии!
Оцените время жизни вашего нового приложения у пользователей на смартфоне и кол-во установок.
(оно равно подмножеству всех проданных устройств на данной платформе пользователям)
Сравните доходы!
Далее — два варианта:
1. понять и осознать
2. минусовать
Зачетная статья!!!
Я двумя руками «ЗА» и согласен с ней!
Разработчики нативов, поймите: вы — практически бесплатные рабы для гигантов IT-индустрии!
Оцените время жизни вашего нового приложения у пользователей на смартфоне и кол-во установок.
(оно равно подмножеству всех проданных устройств на данной платформе пользователям)
Сравните доходы!
Далее — два варианта:
1. понять и осознать
2. минусовать
Полностью согласен с тем, что будущее за HTML!
Эти мобильные устройства все настолько разные, что просто диву порой даешься, как люди умудряются писать мобильные приложения на фоне всех этих мобильных войн. Сейчас пилят рынок мобильных устройств, никто не хочет уступать, каждый считает свои решения более правильными, чем остальные — отсюда и все эти особенности разных мобильных платформ.
Сколько времени ушло на то, чтобы прийти к более-менее единому интерфейсу Интернет — HTML, CSS. И даже сейчас браузеры от разных производителей все же отличаются в деталях реализации механизмов, но, слава Богу, основной функционал работает везде одинаково — на любой ОС, на любой платформе, на множестве современных браузеров.
Нет же, надо было затеять новую войнушку под названием мобильные приложения. Зачем? Ради очередного передела рынка?
Я думаю, что все-таки так или иначе все вернется уже в более тихую гавань, где эти споры более-менее закончены — будут реализованы на всех мобильных устройствах нормальная обработка HTML (5, 6 и т.д.) как способ реализации интерфейса и работы мобильных приложений.
Что бы ни говорили, что новшества — это хорошо, а все же общие стандарты и единообразие — это лучше!
Эти мобильные устройства все настолько разные, что просто диву порой даешься, как люди умудряются писать мобильные приложения на фоне всех этих мобильных войн. Сейчас пилят рынок мобильных устройств, никто не хочет уступать, каждый считает свои решения более правильными, чем остальные — отсюда и все эти особенности разных мобильных платформ.
Сколько времени ушло на то, чтобы прийти к более-менее единому интерфейсу Интернет — HTML, CSS. И даже сейчас браузеры от разных производителей все же отличаются в деталях реализации механизмов, но, слава Богу, основной функционал работает везде одинаково — на любой ОС, на любой платформе, на множестве современных браузеров.
Нет же, надо было затеять новую войнушку под названием мобильные приложения. Зачем? Ради очередного передела рынка?
Я думаю, что все-таки так или иначе все вернется уже в более тихую гавань, где эти споры более-менее закончены — будут реализованы на всех мобильных устройствах нормальная обработка HTML (5, 6 и т.д.) как способ реализации интерфейса и работы мобильных приложений.
Что бы ни говорили, что новшества — это хорошо, а все же общие стандарты и единообразие — это лучше!
Я правильно понимаю, что если в приложении немного арта, то можно не заморачиваться с форматами текстур, а тупо хранить все в 32bpp? И останется только жать «publish» под разные платформы и пить кофе.
Т.е. портирование будет заключаться в поддержке разных размеров/аспектов и специфических для платформ api. Или я что-то упустил?
Т.е. портирование будет заключаться в поддержке разных размеров/аспектов и специфических для платформ api. Или я что-то упустил?
И еще один вопрос. На какое минимальное количество памяти стоит ориентироваться?
А чем вы атласы собираете?
а чтото из free есть?
У lib-gdx есть неплохой packer
У lib-gdx есть неплохой packer
Я не знаю, не видел. Просто я автору задавал подобный вопрос, увидел ваш, дал ссылку.
Вообще в юнити есть встроенный пакер текстур.
Мы пользуемся стандартным от 2D Toolkit.
Вообще в юнити есть встроенный пакер текстур.
Мы пользуемся стандартным от 2D Toolkit.
Вообще в юнити есть встроенный пакер текстур.
Вы имеете в виду то, что перепаковывает текстуры?
TexturePacker — не только и не столько пакует текстуры, сколько именно собирает атласы. И в юнити из коробки собирателя атласов нет.
Вообще, в ex2D, которым мы пользовались — тоже есть встроенный. Но он глючил и нам не понравился. По этому было принято решение заюзать TexturePacker, который вроде как мега-популярен и его юзает чуть ли не каждый второй.
Я имел в виду это:
Texture2D.PackTextures(...)
Description
Packs multiple textures into a texture atlas.
docs.unity3d.com/Documentation/ScriptReference/Texture2D.PackTextures.html
Texture2D.PackTextures(...)
Description
Packs multiple textures into a texture atlas.
docs.unity3d.com/Documentation/ScriptReference/Texture2D.PackTextures.html
создавать атласы real-time? спасибо, не надо. плюс, сжатые не получится
С чего вы взяли что в real-time? В Editor mode.
forum.unity3d.com/threads/169201-TexturePacker-to-Meshes-amp-Prefabs-Importer
вот не плохое решение
вот не плохое решение
> Игру мы писали на Unity
Впринципе, этого достаточно, дабы дальше не читать. Однако я, тоже будучи разработчиком под Android, решил проникнуться сочуствием к братьям меньшим.
> наша задача будет только жать «publish» под разные платформы и пить кофе.
Собственно, это главная часть, остальное можно опять не читать. Посаны на раёне прочитали про Юнити и решили срубить бапки. Какое вообще программирование?
> iPad 2 дает приложению под ресурсы немногим больше 100 Мб RAM
Как же этого нам болезным мало. Всего-то каких-то 100 мегабайт. Для сравнения, в 1991 году, компании LucasArts (Lucas Film Games в девичестве) хватало 5 (пять) МЕГАБАЙТ на производство многочасового интерактивного кинца. Здесь же бедным, сирым и убогим дали всего-то 100 мегабайт.
И да, творение 1991 года я прямо сейчас прохожу с большим удовольствием, порой играю в игры со Спектрума (48 КИЛОБАЙТ НА ВСЕ), а топ гуглоплея забит многомегабайтным говном, ИГРАТЬ НЕЧЕГО.
Так может быть не в мегабайтах дело?
> Например, на градиентах вы увидите весьма неприятный dithering.
А отключить дизеринг слабо? Уж не знаю как в вашей юнити грузятся текстуры, а в нормальном андроиде битмапы можно подгрузить как-то так:
BitmapFactory.Options op= new BitmapFactory.Options();
op.inDither=false;
> столкнетесь с крашами на куче устройств, т.к. если устройство видит неподдерживаемый формат, то пытается его заранее распаковать в 32bpp, а в результате — вылетает по памяти.
Значит, отловить эксепшен и скачать картинку поменьше, мы уже не можем?
> Ведь гонять все эти мегабайты туда-сюда — тоже удовольствие небыстрое.
Действительно, осталось понять ЗАЧЕМ гонять туда и сюда.
> Стоит ли говорить, что все эти танцы с текстурами весьма усложняют пайплайн?
Не стоит, просто кому-то надо написать сборочных скриптов.
> И предстоит вам копаться в настройках своего проекта в Google Play и руками отключать какие-то заведомо фейловые устройства. Ну, или иметь нереальный парк устройств.
Вот за дискриминацию устройств, я бы сразу подавал в суд. Но суд — это долго и дорого, поэтому я бы сразу брал топор и ОТРУБАЛ КРИВЫЕ РУКИ. Дебилоиды-менеджеры так боятся обосраться, что даже не показывают свое говно никому, кроме «сертифицированных» говноедов от самсунга и других топовых вендоров. А что делать мне, если я самсунг в гробу видел и взял девайс (на том самом Mali) от никому не известного вендора? Правильно, мне остается только молча вас ненавидеть и желать вам смерти, самой жестокой и мучительной, когда в гуглоплее я не смогу найти приложение. Мне кидают прямую ссылку, кричат ставь — а я не могу. На меня смотрят с недопониманием. Иногда уже установленные приложения, перестают работать — так как ушлые менеджеры догадались включить проверку устройства. Было приложение — и все, его нет. Не, в самом деле, к комментариям в гуглоплее нехватает кнопки «отрубить вот ему руки». Можно даже с галочкой «отрубать с особым цинизмом, подогрев на костре».
> Думаете, вы все контролируете? А вот фигушки!
Конечно, вы ведь не делаете игру, а используете непонятную магию «юнити», которая делает все за вас.
> А также — зашифруйте все важные хранимые циферки (количество денег у игрока и т.п.), т.к. программ а-ля ArtMoney под дроид тоже хватает.
А какое тебе дело, что я делаю с игрой на своем планшете? Что, читы продавать не выходит? В общем, третий тег, который вы поставили, порекомендую не андроиду, а вам, успешные и эффективные менеджеры. И да, я никогда ничего не куплю, если это у меня вымогают, всеми силами защищаясь от меня же.
В целом, проблем на платформе действительно хватает, но описанное в статье — плачь говноменеджера, который к программистам отношения не имеет.
Впринципе, этого достаточно, дабы дальше не читать. Однако я, тоже будучи разработчиком под Android, решил проникнуться сочуствием к братьям меньшим.
> наша задача будет только жать «publish» под разные платформы и пить кофе.
Собственно, это главная часть, остальное можно опять не читать. Посаны на раёне прочитали про Юнити и решили срубить бапки. Какое вообще программирование?
> iPad 2 дает приложению под ресурсы немногим больше 100 Мб RAM
Как же этого нам болезным мало. Всего-то каких-то 100 мегабайт. Для сравнения, в 1991 году, компании LucasArts (Lucas Film Games в девичестве) хватало 5 (пять) МЕГАБАЙТ на производство многочасового интерактивного кинца. Здесь же бедным, сирым и убогим дали всего-то 100 мегабайт.
И да, творение 1991 года я прямо сейчас прохожу с большим удовольствием, порой играю в игры со Спектрума (48 КИЛОБАЙТ НА ВСЕ), а топ гуглоплея забит многомегабайтным говном, ИГРАТЬ НЕЧЕГО.
Так может быть не в мегабайтах дело?
> Например, на градиентах вы увидите весьма неприятный dithering.
А отключить дизеринг слабо? Уж не знаю как в вашей юнити грузятся текстуры, а в нормальном андроиде битмапы можно подгрузить как-то так:
BitmapFactory.Options op= new BitmapFactory.Options();
op.inDither=false;
> столкнетесь с крашами на куче устройств, т.к. если устройство видит неподдерживаемый формат, то пытается его заранее распаковать в 32bpp, а в результате — вылетает по памяти.
Значит, отловить эксепшен и скачать картинку поменьше, мы уже не можем?
> Ведь гонять все эти мегабайты туда-сюда — тоже удовольствие небыстрое.
Действительно, осталось понять ЗАЧЕМ гонять туда и сюда.
> Стоит ли говорить, что все эти танцы с текстурами весьма усложняют пайплайн?
Не стоит, просто кому-то надо написать сборочных скриптов.
> И предстоит вам копаться в настройках своего проекта в Google Play и руками отключать какие-то заведомо фейловые устройства. Ну, или иметь нереальный парк устройств.
Вот за дискриминацию устройств, я бы сразу подавал в суд. Но суд — это долго и дорого, поэтому я бы сразу брал топор и ОТРУБАЛ КРИВЫЕ РУКИ. Дебилоиды-менеджеры так боятся обосраться, что даже не показывают свое говно никому, кроме «сертифицированных» говноедов от самсунга и других топовых вендоров. А что делать мне, если я самсунг в гробу видел и взял девайс (на том самом Mali) от никому не известного вендора? Правильно, мне остается только молча вас ненавидеть и желать вам смерти, самой жестокой и мучительной, когда в гуглоплее я не смогу найти приложение. Мне кидают прямую ссылку, кричат ставь — а я не могу. На меня смотрят с недопониманием. Иногда уже установленные приложения, перестают работать — так как ушлые менеджеры догадались включить проверку устройства. Было приложение — и все, его нет. Не, в самом деле, к комментариям в гуглоплее нехватает кнопки «отрубить вот ему руки». Можно даже с галочкой «отрубать с особым цинизмом, подогрев на костре».
> Думаете, вы все контролируете? А вот фигушки!
Конечно, вы ведь не делаете игру, а используете непонятную магию «юнити», которая делает все за вас.
> А также — зашифруйте все важные хранимые циферки (количество денег у игрока и т.п.), т.к. программ а-ля ArtMoney под дроид тоже хватает.
А какое тебе дело, что я делаю с игрой на своем планшете? Что, читы продавать не выходит? В общем, третий тег, который вы поставили, порекомендую не андроиду, а вам, успешные и эффективные менеджеры. И да, я никогда ничего не куплю, если это у меня вымогают, всеми силами защищаясь от меня же.
В целом, проблем на платформе действительно хватает, но описанное в статье — плачь говноменеджера, который к программистам отношения не имеет.
Впринципе, этого достаточно, дабы дальше не читать.
Аргументируйте? На Unity очень много отличных профессиональных проектов. Все дело в низком пороге вхождения, что приводит к тому, что писать игры на Unity пытаются все, кому не лень.
Для сравнения, в 1991 году, компании LucasArts (Lucas Film Games в девичестве) хватало 5 (пять) МЕГАБАЙТ на производство многочасового интерактивного кинца. Здесь же бедным, сирым и убогим дали всего-то 100 мегабайт.
Софтварным рендерингом можно и не такое начудить. На современных ПК такая проблема вообще стоит нечасто, ибо память GPU и CPU разделена
Действительно, осталось понять ЗАЧЕМ гонять туда и сюда.
Может, имелась в виду скорость загрузки данных? Загрузить ARGB8888 в видеопамять действительно будет несколько затратнее по времени, чем пожатый формат.
Но вообще, конечно, распаковывать всё в ARGB8888 — это лютое зло. Нужно бы делать нормальный сборщик, который по нажатию одной кнопки выдаст пакеты под все форматы. Ну или пользоваться чем-то заведомо совместимым типа ETC
Значит, отловить эксепшен и скачать картинку поменьше, мы уже не можем?
Не проверял на андроиде, но на iOS, например, эксепшены чаще всего отключают во имя производительности.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Кросс-платформенная мобильная игра и палки в колеса от Android