Как узнать размер экрана телефона юнити
Всем привет! Меня зовут Илья, я работаю разработчиком мобильных игр на Unity вот уже несколько лет и сегодня хотел бы поделиться небольшим чек-листом (или гайдом) по оптимизации мобильных игр для начинающих. В этой статье мы коснемся как графических, так и других аспектов оптимизации "на скорую руку" когда вам нужно быстро поднять FPS ваших мобильных игр.
По большей мере речь пойдет про оптимизацию 2D игр, чтобы их можно было запустить даже на кипятильнике.
Итак, с предисловием закончили. Поехали!
1) Постарайтесь использовать одну камеру на сцене. Чем больше камер вы используете, тем выше нагрузка на CPU.
2) Избегайте использования пост-обработки, это серьезно увеличивает нагрузку на GPU за счет того, что движку приходится обрабатывать повторно каждый кадр при отрисовке.
4) Используйте MSAA не выше 4X на любых мобильных платформах.
5) Используйте Forward-режим рендеринга без использования HDR, чтобы снизить нагрузку на GPU.
6) Выставьте необходимые Clear Flags на камере, чтобы указать, что нужно очищать при рендеренге каждый кадр.
7) При разработке 3D игр, также настройте допустимый Clipping Planes для ограничения области прорисовки дальних объектов.
1) Старайтесь использовать облегченные API, как Vulkan или Metal если это возможно. Для 2D игр достаточно OpenGL 2.
2) Используйте Occlusion Culling для выгрузки объектов вне поля зрения.
3) Используйте только запеченное освещение, тени и Reflection Probes (от них лучше отказаться вовсе). Не используйте ни в коем случае Realtime расчеты.
4) Старайтесь использовать Static и Dynamic Batching для ваших объектов для объединения геометрии.
5) Старайтесь не использовать процедурные системы частиц.
6) Старайтесь по минимуму использовать анимации. Где это возможно, анимируйте объекты через ваши скрипты или, к примеру через DOTween.
7) Установите значение флага "Realtime Pixel Lights" на 0, если это возможно.
8) Выключите Soft Particles.
9) Старайтесь использовать простые шейдера с минимальным количеством инструкций.
10) Избегайте сэмплинга в Reflection Probes.
11) Используйте общий материал для ваших объектов.
12) Используйте Gamma рендеринг вместо Linear.
13) Постарайтесь использовать URP-рендеринг вместо Legacy (Built-in).
14) Постарайтесь изучить и использовать ShaderVariants в вашем проекте., для уменьшения нагрузки на GPU.
15) При добавление/удалении шейдеров в проекте, держите актуальным список Always Inculded Shaders.
16) Иногда требуется разогреть видео-чип перед стартом игры, чтобы исключить микро-фризы при первой отрисовке объекта. Для этого вы можете прогревать их в процессе загрузки игры, инициализируя объекты на сцене Preload.
1) Используйте Sprite атласы для интерфейсов и объединения графики в единый спрайт. Таким образом ваши объекты будут занимать меньше памяти на GPU. Желательно использовать последнюю версию инструмента для работы с атласами.
2) Постарайтесь избегать прозрачности в спрайтах.
3) Включите "Optimize Game Objects" при импорте мешей с ригом.
4) Минимизируйте количество деревьев в анимации.
5) Уменьшите количество костей и вертексов для анимации.
6) Используйте уровни отрисовки (LOD) для дальних объектов (касаемо 3D графики).
7) Избегайте Multi-Pass шейдеров.
8) Попробуйте использовать стриминг текстур.
9) Настройте оптимальные параметры для компрессии текстур, 3D моделей, анимаций и другого контента. Если есть необходимость - настройте MIPMAPS для тяжелых объектов.
10) Отключите Read/Write в импорте ассетов, где это возможно.
11) Настройте предзагрузку шейдеров, которые необходимы в геймплее.
12) Отключите все анимационные контроллеры. Включайте их только при необходимости, поскольку даже пустые Animation Controller создают нагрузку на GPU.
13) Не воспроизводите вместе Unity-анимации и DOTween анимации.
1) Используйте Sprite атласы. Это важно!
2) Избегайте изменения на UI каждый кадр отрисовки. Лучше изучите как работают события и делайте изменения через слушатели.
3) По возможности откажитесь от Rich Text, автоматической подгонки размера текста. В идеале - лучше использовать TextMesh вместо Unity Text.
4) Не используйте автоматическую систему слоев в UI. Также постарайтесь сократить количество UI слоев до 2х.
5) Настройте материалы у вашего UI. Не используйте UI без материалов, желательно не использовать стандартные шейдера.
6) Старайтесь не использовать пустые и невидимые объекты с компонентами Image. Все они влияют на нагрузку GPU.
1) Включите Straming на длинных аудио-клипах.
2) Отключите предзагрузку аудио-файлов там, где она не нужна.
3) Настройте оптимальную компрессию аудио.
4) Ограничьте хранение ссылок на аудио в памяти.
5) Настройте Bufffer size на Best perfomance.
6) Отключите все Plugins для Audio. Уменьшите количество потоков в половину от стандартного значения.
7) При правильном использовании Mixer можно снизить нагрузку на CPU, разбив отдельные звуки как дорожки микшера.
1) Настройте Addressables вместо Asset Bundles. Обо всех преимуществах в экономии памяти вы можете почитать на сайте Unity.
2) Избегайте использования ресурсов из директории "Resources".
3) Уменьшите размер вашей сборки при помощи CDN и последующей загрузки с него ресурсов.
1) Не используйте бесконечные Coroutine-функции, старайтесь минимизировать их размер.
2) Используйте пулы объектов, вместо реинициализации и уничтожения объектов со сцены.
3) Используйте ваш менеджер управления состояниями. Старайтесь не использовать обновления состояния объектов через Update.
4) Старайтесь убрать все неиспользуемые ссылки в объектах. Старайтесь не использовать на глобальных объектах тяжелых ссылок.
5) Постарайтесь вручную контролировать Garbadge Collector.
6) Избегайте генеративных методов Garbadge Collector-а, таких как FindObjectsOfType.
8) По возможности, старайтесь не хранить ссылки на все подряд в памяти. Для удобства, можете использовать Zenject для внедрения зависимостей.
9) Не используйте SpriteAtlas.GetSprite во избежание утечек памяти.
1) Оставьте только те Build Targets, которые вы хотите использовать.
3) Используйте GPU Skinning, если это возможно.
4) Не забудьте выставить флаг "static" у тех объектов на сцене, которые являются статичными.
5) В иерархии сцены, постарайтесь не использовать динамичные объекты с большим количеством дочерних или родительских объектов.
6) Включите Multithreaded rendering и Graphics Jobs в настройках проекта.
Соблюдая данный чек-лист вы сможете добиться значительного уменьшения Draw Calls, а также оптимизировать без лишних затрат ваш проект. Желательно задуматься об оптимизации вначале работы над вашим проектом, поскольку это может сэкономить вам нервы в дальнейшем.
Надеюсь, вы подчерпнули для себя что-то новое. И буду рад вашим дополнениям!
P.S. Если будет интерес, в следующих статьях могу подробнее рассказывать о каждом разделе с подробным объяснением и сравнениями.
1. Не используйте этот чеклист пока не сделали первую игру
2. Не используйте этот чеклист пока не понимаете что значит любой из этих пунктов
3. Не думайте об оптимизации, думайте о геймплее, когда ваша игра взорвет рынок - наймёте Илью Сергеича и он оптимизирует вам игру.
Если заранее об оптимизации хоть чуть чуть подумать то это может сыграть на руку. Тот же Google play больше шансов даст фичеринг для более оптимизированной игры.
чтобы думать об оптимизации надо понимать как она устроена и иметь большой опыт использования того что используется в игре. Все эти пункты никак не помогут тому, у кого нет этого опыта. Сейчас все бросятся оптимизировать и умрут по пути к вершине оптимизированного счастья.
Тут соглашусь, надо сначала по кирпичикам все разобрать а в идеале вообще свой движок написать чтобы понимать как работает. Хотя бы примитивный.
я за 12 лет опыта работы вывел золотое правило: Оптимизация только после успешного прототипа, который подтвердил потребность целевой аудитории в данном продукте. Естественно я уже знаю где могу упасть и соломка везде где нужно расстелена, а начинающим разработчикам без собственных граблей это недостижимо. Таков Путь.
большинство пунктов выполняются автоматически, реально полезные советы - про пулы и переход на LWRP
LWRP за собой кучу проблем несет, бездумно его использовать не стоит.
Пулы нужны только если объектов много и они более менее динамически в игре появляются исчезают, для большинства новичков они нафиг не нужны. В общем текст для новичков в целом, а использование его убьет их до достижения уровня, на котором это можно нормально использовать.
Пулы с динамикой очень полезная вещь в любой более менее динамичной игре, в той же 3 в ряд Пулы пригодятся ой как.
что лучше динамические или статические пулы ? )))
Что лучше хлеб или батон. Всему есть свое применение.
этим ответом я мог ответить вместо вопроса вызвавшего этот ответ, в этом и был смысл. Не надо навязывать собственные мнения другим в виде пунктов. Использование пулов должно происходить осознанно, только в тот момент когда человек действительно в них будет нуждаться, заранее пулить всё подряд это пустая трата времени, как и большинство всех этих пунктов. Я понимаю что хочется поделиться болью и пережитыми страданиями, но надо понимать целевую аудиторию таких статей.
Насчёт URP в новых версиях он более менее стабильный. Вообще если речь идёт о maximum power то лучше вообще отказаться от unity 🤣
Unity выбирают не изза максимум повер, хотя сейчас я бы дал прикурить много кому из анрильщиков с помощью HDRP. Так что не надо на юнити бычок крошить. Юнити имеет гораздо ниже порог входа и в этом его прелесть, а ещё его проще менять под себя.
Порог входа ниже, но это накладывает на себя минусы. Люди бегут фигачить огромные проекты, еле еле понимая как устроен игровой движок, а на выходе получается срань похлеще киберпанка в плане оптимизации и лютого треша 🤣
По возможности, старайтесь не хранить ссылки на все подряд в памяти. Для удобства, можете использовать Zenject для внедрения зависимостей.
Который будет хранить тысячи лишних ссылок вместо вас (:
Ну на большом проекте все же это будет куда удобнее и для гейм дизайнеров и для разработчиков.
Я сам на проектах Zenject использую. Но он тоже не панацея)
Не панацея, но для начала пойдёт. Если правильно использовать впринципе не плохое решение, но нужно все же понимать как он работает и не плодить лишнего.
Тестировал производительность URP и он всегда был медленее чем Built-In рендеринг.
То же самое с Вулканом против OpenGL.
Хм, у меня обратная картина. Возможно стоит изучить старые устройства. Но для 2d графики opengl 2 будет эталон если не использовать какие то новороченные функции.
Делать анимации скриптами прожорливее 🤔
Нет, простые анимации лучше сделать кодом, а не при помощи системы анимаций Unity. Она более прожорливая
Не уверен. Делал вращение монеток в 3д и поскольку их было много, то через Animation было выше на 3-5 фпс. Плюс можно выставить culling всякие
Наверное от ситуации зависит, но надо будет проверить с DOTwin 🙌
дотвин помойка, быстрее всего вращать кучи объектов поможет ECS :))
Можно подробнее? Спасибо.
Верно. Анимация - это заранее заданный путь для движения монетки например. Он один раз в памяти прописался и спокойно выполняется по кругу, то есть один раз съест немного оперативки и совсем немного процессора будет жрать в процессе выполнения. Через скрипт анимация может жрать сильно больше оперативки и процессора, просто потому что каждый следующий кадр приходится про считывать куда поместится монетка например
Не используйте автоматическую систему слоев в UI
Что за автоматическая система слоёв, поясните, пожалуйста.
Content size fitter в сочетании с другими элементами, например Vertical Layout Group
Т.е. имелось в виду автоматическую систему размеров, а не слоёв, полагаю.
Но UI канвас, насколько мне известно, обновляется только при изменении содержимого, так что вроде это не должно быть проблемой, если только там не какие-то динамически изменяемые каждый фрейм элементы. И это решается отдельным канвасом с выносом туда таких элементов.
Лол, а что тогда использовать? Свои решения городить?
Например Content size fitter очень часто выручает для вёрстки под разные экраны
Не стоит юзать их для автоматической подгонки UI везде где не приколочено. Постараться минимизировать это
Тестировал на мид/лоу-енд девайсах. На топовом железе разницы не сильно видно.
У меня лично URP помог таки поднять FPS на 2D игре. Возможно суть не в самом URP, а в шейдерах
Как минимум в 6ом пункте последнего абзаца 🤣
Недостаточно!)
Burst и Jobs уже в нормальном состоянии, пора их вводить в оборот.
Хм, возможно это будет полезно включить да в список
Жаль, что Entities еще не довели до ума.
Полный DOTS стак куда более приятный для разработки когда его раскуришь.
5) Настройте материалы у вашего UI. Не используйте UI без материалов, желательно не использовать стандартные шейдера.
А это что значит?
Built in шейдера напичканы слишком разной всячиной которая по факту не нужна на 90% проектов.
я про первую половину - что значит, не использовать ui без материалов?
В настройках UI компонентов указывать материал, желательно на базе своего кастомного шейдера
Все равно плохо понимаю о чем речь, можно какую-нибудь статью на тему того, чем плох UI-Default?
в дефолте куча параметров которые не используются, речь идет о том что это якобы будет занимать лишнюю память и время на отрисовку, но этим можно и нужно пренебречь
Может быть, речь о Standard шейдере? там правда овердофига всего, в дефолте же ничего нет кроме колор маски и альфа клипа
ну там ещё есть шейдер варианты, они автоматом лишнее удаляют если оно не используется, но кому это нужно если есть ПУНКТ ))
Про варианты тоже написано было
Речь про overlapping, его можно минимизировать с использованием своих супер простых шейдеров. Можно конечно использовать варианты шейдеров, но не знаю насколько это будет эффективнее, под капот не лез. По старинке, чем меньше процедур и мусора в шейдерах, тем лучше
Используйте GPU Skinning, если это возможно.
Вот прямо очень плохой совет. Сколько не пробовал, всегда ужасный дроп кадров от просчета скинов на гпу. Причина проста - мобильные гпу слабые и перегреваются, а процессоры многоядерные и довольно мощные.
Возможно на пк эта настройка наоборот спасает, но на мобилках боль.
Интересный кейс, надо будет разобрать. Возможно есть ряд gpu которые умеют с ним работать.
Очень познавательно, с удовольствием почитал бы более подробные материалы на эту тему!
1) Не используйте бесконечные Coroutine-функции
но почему?
Просто не знаю, вроде порой удобный способ запустить корутину с while(true) и пусть работает себе пока объект активен 🤔
Поговаривают что invoke лучше
Hey guys, I had always considered Unity Invoke method to be slow because it was based on…Там пример с запуском invoke и coroutine миллион раз подряд(а не одна корутина против циклического запуска invoke раз за разом), в такой ситуации вообще ни тот ни другой не нужно использовать. Если событие нужно вызвать разок через какое то время и забыть, то invoke подойдёт, а если это сложное событие где нужно lerp проводить в процессе то нет и если бесконечный цикл внутри корутины тут опять же invoke бесполезен, есть invokeRepeat, но опять же он не будет иметь логики внутри. А если мне нужно чтобы проверка условия проводилась, причем если игрок близко ждал один таймер, если далеко уходил на другой интервал, то не подходит invokeRepeat, а обычный invoke вызывать как раз таки лишнее время, чем корутина 1. Возможно речь шла о том что не надо делать так чтобы корутина сама себя в конце запускала? 🤷🏻♂️ ред.
16) Иногда требуется разогреть видео-чип перед стартом игры, чтобы исключить микро-фризы при первой отрисовке объекта.
На сковороде прогреть лол. Вот кому поможет этот совет? Речь идёт о компиляции шейдеров. Так и пишите это. Скомпилируйте все необходимые шейдеры заранее используя ShaderVariantCollection. Делать это нужно один раз при запуске игры. Если шейдеры уже скомпилированны, повторной компиляции не будет. Инициализовать объекты ради компиляции шейдеров не нужно.
Не только в шейдерах дело, в том то и дело. Есть ещё текстуры и прочее. Да, термин прогреть немного странный 🤣 это больше касается динамики, в частности партиклы
Я, конечно, не гуру, но все же.
Работа с камерой:
1) Одну камеру использовать не всегда удобно и выгодно с точки зрения оптимизации. Часто можно одной камерой рисовать трехмерную сцену, а другой камерой рисовать меню например (да как угодно можно).
7) Лучше нормально лоды сделать и не выдумывать.
Работа с рендерингом:
4) Это не имеет смысла часто. Лучше бы расписали что это такое и зачем.
6) Анимации гораздо эффективнее работают зачастую, они позволяют заранее запомнить то, что должен высчитывать скрипт каждый кадр.
16) Тут прямо очень надо разъяснить.
Работа с ресурсами:
1) Это тоже далеко не всегда сработает, есть куча особенностей работы с атласами, часто они могут только навредить (например можно получить атлас, который начнет крашить айфоны из-за своих размеров).
2) А почему? Вот это было бы полезно расписать. Прозрачность не плохая сама по себе, она просто плохо сжимается.
13) Не вижу в этом ничего плохого.
Оптимизация кода:
1) В этом нет ничего плохого, часто через них выгоднее сделать логику даже. Лучше распишите почему считаете их неэффективными.
2) Часто это отнимает ценную оперативку т увеличивает нагрузку на процессор (нужно как-то управлять пулом)
6) В этом нет ничего плохого, если они выполняются не часто, при инициализации например
Настройка Player Settings:
2) Это имеет очень много подводных камней.
5) Почему этот пункт здесь?
6) При неумелом использовании это только навредит
По итогу я специально придираюсь, уж извините, но мне кажется, что многое в статье не поможет, а часто даже навредит, начинающим разработчикам
Узнать разрешение экрана телефона можно через настройки, сторонние приложения или с помощью снимка экрана. В статье расскажем, как узнать разрешение экрана смартфона всеми способами.
Как узнать разрешение экрана телефона через настройки?
Узнать разрешение экрана телефона может быть необходимо при работе с определенными программами или приложениями. Если они совместимы, то и работать программа будет без нареканий. Если же разрешение не соответствует требованиям, работа с приложением может сопровождаться ошибками, искажением изображений и так далее. Кроме того, точное разрешение позволяет подобрать подходящее изображение, например, для фона рабочего стола или экрана блокировки.
Не на всех мобильных устройствах разрешение экрана можно узнать в настройках. Однако в первую очередь стоит попробовать именно этот способ, так как он один из самых легких и быстрых. Например, на смартфонах производства Samsung этот метод гарантированно сработает. Чтобы узнать разрешение экрана, пользователю нужно:
Здесь будет доступно несколько значений, одно из которых активировано в данный момент. Это количество точек — текущее разрешение экрана телефона. Самое большое число из перечисленных значений является максимальным разрешением экрана телефона, которое можно выбрать вручную. Именно это число и стоит использовать для сравнения с требованиями приложений или программ.
Как узнать разрешение экрана через приложение AIDA64?
На многих смартфонах, например, Xiaomi (Redmi), узнать разрешение экрана в настройках нельзя. Для этого необходимо использовать сторонние приложения, которые считывают информацию о всех показателях смартфона (температура, состояние датчиков и т.д.) и предоставляют ее владельцу в понятном виде. Одно из таких бесплатных приложений — AIDA64. Чтобы узнать разрешение экрана, следуйте простой инструкции:
Как узнать разрешение экрана с помощью снимка экрана?
Помочь быстро узнать разрешение экрана смартфона может обычный скриншот. Чтобы воспользоваться этим способом, необходимо:
Ребят, я не могу понять, как правильно организовать маштабирование сцены в Unity3D под все экраны? Уже облазил весь гугл, но так и не нашел конкретного решения этой проблемы.
Я сделал скрипт, который вычисляет значение size у компонента Camera, которое должно быть равное половине высоты экрана в пикселях. Все круто, обзор камеры увеличивается/уменьшается в зависимости от размеров экрана. А как быть со спрайтами то? Мне придется каждый спрайт маштабировать(scale) чтоли в зависимости от экрана? Или как-то это по другому делается?
В Unity по умолчанию меняется только ширина экрана. Высота считается неизменной (в юнитах расстояния). То есть если есть ортографическая камера с размером 2, то это значит что высота экрана равна 4 всегда и везде, при любом отношении сторон. То есть на более широких экранах мы видим большее количество объектов на сцене. Чаще всего такой вариант прокатывает - для всяких топдаун шутеров и прочего просто широта обзора становится шире. А там где ширина поля должна быть фиксированная обычно делают с расчётом на самый квадратный аспект экрана (4 к 3 на айпаде), а для более широких (или высоких) дорисовывают задник чтобы не было пустоты.
Но иногда приходится "переворачивать" эту логику константной высоты и делать константную ширину. Тогда как раз динамически вычисляем size у камеры в зависимости от референсного значения ширины и выставление где-нибудь при старте игры (если не будет возможности менять размер окошка). В этом случае побочным эффектом изменения ортографического размера камеры будет увеличение или уменьшение размеров спрайтов по высоте (чего не происходит в стандартной модели с константным размером по высоте). На спрайты ничего вешать не надо, они рисуются через камеру и изменение size у камеры имеет эффект увеличения или уменьшение размеров спрайтов
KumoKairo, допустим у меня есть сцена, где камера будет неподвижна, и мне нужно видеть определенный геймплей в этой камере. И чтобы этот геймплей умещался на всех экранах. Также имеется фон, который как я понял, будет обрезаться, если ширина экрана становится меньше, чем ширина фона.
А там где ширина поля должна быть фиксированная обычно делают с расчётом на самый квадратный аспект экрана (4 к 3 на айпаде), а для более широких (или высоких) дорисовывают задник чтобы не было пустоты.Тоесть делаем под самый более менее квадратный экран, и следовательно на всех более широких экранах будет по любому все что нужно видно. Вы это имели ввиду? А что, если нужно персонажа четко в левой стороне экрана устанавливать? Или какое-нибудь GUI, которое отображается по краям вверху? Если мы все это расставим для экрана 4 к 3, то при более широком экране, все эти элементы(GUI, персонаж) будут уже не у краев.
По поводу GUI это отдельная история, посмотри хотя бы туториалы на сайте юнити. Всё гораздо проще, чем ты думаешь
По поводу GUI это отдельная история, посмотри хотя бы туториалы на сайте юнитиНу я смотрел разные уроки по Unity3d с офф сайта, но про GUI ничего не смотрел. Ну я понял про что Вы имели ввиду в понимании "проще". Там якоря(привязки всякие) есть, да?:)
Ну хорошо, с GUI опустим. А что по поводу персонажа, который должен в правой стороне экрана стоять?:)
Там и якоря и масштабы, различные варианты. Выбираешь что тебе удобнее в данном конкретном случае. По поводу персонажа, я так понимаю он не спрайт, который можно так же как элемент GUI вывести, можно тоже несколькими способами выводить. Можешь тупо математикой вычислить, а можешь из координат гуя перевести в мировые и выводить в этом месте всё что пожелаешь
Можешь тупо математикой вычислить, а можешь из координат гуя перевести в мировые и выводить в этом месте всё что пожелаешьДа я знаю, что можно разными способами решить задачу. Но не хотелось бы, чтобы это были какие-то костыли. Более проще и понятнее.
Да, и еще хотел спросить несколько вопросов по поводу спрайтов для мобильных платформ:
1. Нужно ли их маштабировать, или лучше в фотошопе подогнать все спрайты между собой, как хотелось бы их видеть, и потом уже выводить в реальном размере с маштабом (1, 1, 1)?
2. Какого разрешения должны быть спрайты, чтобы не было искажения в качестве и всяких артефактов при выводе их на разных экранах? Нужно ли под определенные стандарты экранов делать несколько прототипов спрайтов с разным разрешением? Короче вопрос общего характера, по поводу правильного вывода спрайтов на мобильных платформах.
Не очень хотелось бы начинать игру и столкнуться со всеми этими проблемами, и после этого переделывать весь проект. Лучше заранее узнать все что нужно в данной области( разработка игр под мобильные платформы ), и потом уже делать более менее правильно.
Правильного нет, есть оптимальный для конкретного проекта. Самый простой способ - рисуешь и нарезаешь спрайты под самое большое разрешение, юнити потом сама его уменьшит под девайс. Если будут проблемы, нужно будет настроить антиальясинг и тому подобные вещи. Можно хранить несколько наборов графики и подключать наиболее подходящий для девайса, можно собирать бандлы и закачивать с инета нужный, чтобы уменьшить вес приложения в сторе. Можно использовать готовые ассеты для того, чтобы держать несколько наборов графики. Вариантов куча.
Правильного нет, есть оптимальный для конкретного проектаНу я же говорю, проект мобильной игры, 2d, жанр аркада. Неужели все аркады под мобильные девайсы делаются в плане спрайтов по разному и люди еще не определили как лучше будет? Самый простой способ - рисуешь и нарезаешь спрайты под самое большое разрешение, юнити потом сама его уменьшит под девайс
Это увеличит размер файла, который нужно будет скачивать на игровых площадках. Можно хранить несколько наборов графики и подключать наиболее подходящий для девайса можно собирать бандлы и закачивать с инета нужный, чтобы уменьшить вес приложения в сторе
Вот это мне более менее нравится. Но что если нет инета у человека? Хотя, как он тогда на стор зашел.
bretbas
> Ну я же говорю, проект мобильной игры, 2d, жанр аркада. Неужели все аркады под
> мобильные девайсы делаются в плане спрайтов по разному и люди еще не определили
> как лучше будет?
Ты не поверишь, но даже с такими ограничениями куча вариантов реализации :)
bretbas
> Это увеличит размер файла, который нужно будет скачивать на игровых площадках.
И что? хочешь - делаешь, не хочешь - не делаешь. Это как с машинами, если ты ездишь на Мерседесе и тебе не нравятся ВАЗы, то это же не значит что никто не будет ездить на ВАЗах
По поводу нарезанных разных вариантов, автоматического уменьшения или ассетбандлов - вы совершенно не туда свои силы направили. Как я понял, у вас с Unity не сильно много опыта, поэтому сделайте простейшим вариантом с одной нарезкой под большое разрешение и не парьтесь пока
Это как с машинами, если ты ездишь на Мерседесе и тебе не нравятся ВАЗы, то это же не значит что никто не будет ездить на ВАЗахЕго вообще нет:) Я просто не знаю, что мне делать. Хочется сразу все. Прежде чем заниматься Unity, я подтянул знания в C++, паттернах. Попробовал написать свой игровой движочек с одной игрулиной. Но когда я зашел в Unity, я сразу начал путаться. И до сих пор путаюсь. К примеру, я никак не могу привыкнуть к тому, что я не могу наследоваться от GameObject. В своем движке, когда я писал его, я сделал эту возможность, и прежде чем делать полиморфно различных врагов, я подготавливал заранее GameObject с нужными всем врагам компонентами и функционалам. Потом просто наследовался от этого GameObject и создавал разных врагов на его прототипе. В Unity3d я никак не могу привыкнуть к тому, что мне нужно так сказать наследоваться от компонентов/скриптов, чтобы реализовать полиморфное поведение.
Я кстати посмотрел видео, которое Вы мне прислали. Я так понял, что обрезка будет в любом случае - или по высоте, или по ширине.
Да, совсем без обрезки не обойтись, тут зависит от конкретного примера и конкретных требований
Тогда надо цель поставить -
- либо вы копаетесь в технических деталях, заморачиваетесь по каждому чиху и реализуете свои собственные решения
- либо делаете какой-то конечный продукт-игру, и цель рабочего процесса не сделать "идеально", а доделать проект до конца.
Копаться в тонкостях проще и приятней всего, можно без зазрения совести распыляться до бесконечности и при этом иметь какой-то быстрый результат на руках. Я сам этим постоянно занимаюсь и постоянно стараюсь с этим бороться. Но если идея именно в этом, без какого-то конкретного проекта, то всё круто)
Потом просто наследовался от этого GameObject и создавал разных врагов на его прототипе.Скорее всего вам нужны префабы - прототипы объектов с настроенными компонентами. Можно создавать из кода и настраивать разные варианты на основе прототипа. Скорее всего вам нужны префабы - прототипы объектов с настроенными компонентами. Можно создавать из кода и настраивать разные варианты на основе прототипа. Копаться в тонкостях проще и приятней всего, можно без зазрения совести распыляться до бесконечности и при этом иметь какой-то быстрый результат на руках. Я сам этим постоянно занимаюсь и постоянно стараюсь с этим бороться. Но если идея именно в этом, без какого-то конкретного проекта, то всё круто)
С идеи в тонкостях копаться тоже приятно. Только долго, ибо заморачиваешься над всякой фигней. Хотя в некоторых случаях это не фигня. Вот к примеру, задавал на офф форуме Unity3d, почему поиск/сравнение и тд тегов у игровых объектов идет через string. Это же ужасно в плане производительности. Так и не дождался ответа.
Разрешением экрана смартфона принято называть величину, определяющую количество точек на единицу площади. Говоря простыми словами, разрешение экрана – это соотношение ширины и высоты дисплея смартфона. Раньше практически все смартфоны производились со стандартными показателями разрешения дисплеев – 1920х1080, 1280х720 пикселей и т.д. А сейчас выпускается огромное разнообразие моделей смартфонов с различными разрешениями. В сегодняшней статье поговорим о том, как определить разрешение экрана своего телефонного устройства:
Простой способ узнать разрешение экрана
Способ №1 Официальный сайт
Проще всего узнать точные показатели разрешения своего смартфона, посетив официальный сайт производителя. Для этого нужно ввести в поисковую строку любого поисковика следующую фразу: “LG K8 официальный сайт” (вместо “LG K8” укажите название модели своего смартфона). Поисковик выдаст список сайтов, среди которых необходимый сайт будет присутствовать в числе первых.
Там можно будет ознакомиться со всеми характеристиками своего устройства. Также производители часто указывают разрешение экрана и на упаковке от телефона или же в инструкции по использованию. Если по каким-либо причинам инструкция и упаковка от смартфона не сохранились, а посещать сайт производителя нет желания, то переходим к следующему способу.
Способ №2 Скриншот
Данный способ подходит для любых моделей смартфонов. Рассмотрим пример на смартфоне LG K8:
• Сделайте скриншот экрана. Практически на всех моделях смартфонов скриншот делается путем одновременного нажатия сразу двух клавиш: клавиша уменьшения громкости звука + кнопка выключения.
• Сделав скриншот, найдите его в галерее и вызовите контекстное меню. Чаще всего контекстное меню вызывается посредством длительного нажатия на изображение.
• Перейдите в раздел “Сведения”, в котором и будут присутствовать показатели разрешения.
К сожалению, данный способ не совсем точный. Это объясняется тем, что разрешение экрана можно менять в настройках, поэтому в случае с указанным примером можно будет определить только тот показатель разрешения, который установлен в настройках на данный момент. Также стоит отметить, что на некоторых моделях смартфонов указанное в характеристиках максимальное разрешение экрана становится доступным лишь в определенных условиях.
В заключение стоит упомянуть еще об одном способе. В некоторых моделях смартфонов параметры разрешения экрана можно отыскать в разделе общих настроек, который обычно называется “Экран” или ”Дисплей”.
Читайте также: