Как адаптировать экран под все разрешения unity 2d

Обновлено: 05.07.2024

Ребят, я не могу понять, как правильно организовать маштабирование сцены в 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. Это же ужасно в плане производительности. Так и не дождался ответа.

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

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

Для данного руководства о том “как это делается” мы решили использовать четыре разрешения экрана: Phone HD в портретной ориентации (640 x 960) и альбомной (960 x 640) и Phone SD также в портретной (320 x 480) и альбомной (480 x 320). Изначально компоновка была настроена под Phone HD портретную ориентацию и разрешение.

Using anchors to adapt to different aspect ratios

Элементы интерфейса по-умолчанию привязаны к центру родительского прямоугольника. Данное означает что они сохраняют постоянное смещение относительно центра.

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

Одним из способов сохранить расположение кнопок в области экрана является изменение компоновки таким образом, чтобы места их расположения были связаны с их соответствующими углами на экране. Привязка левой верхней кнопки может быть также установлена в левом верхнем углу при использовании в инспекторе выпадающего списка Anchors Preset (наборы привязок), или путём перетаскивания треугольных ручек привязок в видовом окне сцены (Scene View). Лучше сделать это пока текущее разрешение экрана, установленное в игровом режиме (Game View) является тем разрешением, для которого изначально всё и было задумано, где места расположения кнопок были бы подобраны более разумно и как говориться к месту.(Ознакомьтесь со страницей UI Basic Layout для получения более подробной информации по привязкам.). Так же например привязки для левой нижней и правой нижней кнопок могут быть выставлены в левый нижний и правый нижний угол соответственно.

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

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

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

Данное означает что кнопки должны становиться меньше настолько же, насколько в процентном соотношении становиться меньше сам экран. Другими словами, масштаб кнопок должен быть привязан к масштабу размеров экрана. Вот где может помочь компонент Reference Resolution

Масштабирование с компонентом Screen Size

Компонент Canvas Scaler может быть добавлен в корень Canvas - игровой объект (Game Object) со встроенным в него компонентом Canvas, все интерфейсные элементы которого являются его потомками. Он также создаётся по-умолчанию во время создания нового компонента Canvas через меню GameObject.

В компоненте Canvas Scaler вы можете установить его UI Scale Mode в Scale With Screen Size. В данном режиме масштабирования вы можете определить какое разрешение использовать в качестве базового. Если текущее разрешение больше или меньше базового, фактор масштабирования компонента Canvas устанавливается соответственно так, чтобы все элементы интерфейса масштабировались в большую или меньшую сторону вместе с разрешением экрана.

In our case, we set the Canvas Scaler to be the Phone HD portrait resolution of 640 x 960. Now, when setting the screen resolution to the Phone SD portrait resolution of 320 x 480, the entire layout is scaled down so it appears proportionally the same as in full resolution. Everything is scaled down: The button sizes, their distances to the edges of the screen, the button graphics, and the text elements. This means that the layout will appear the same in the Phone SD portrait resolution as in Phone HD portrait; only with a lower pixel density.

Чего стоит опасаться: так это того, что после добавления компонента Reference Resolution, важно также проверять как будет выглядеть компоновка с другими соотношениями сторон. Установив разрешение обратно в Phone HD альбомное, можно заметить как кнопки стали больше, чем должны быть (и для чего должны были быть использованы).

Причина, по которой кнопки при альбомном соотношении сторон становятся больше кроется в том, как работают настройки базового разрешения (Reference Resolution). По-умолчанию они сравнивают ширину текущего разрешения с шириной базового и как результат всё на экране масштабируется основываясь на коэффициенте масштабирования, получаемом из этой разницы. Если текущее альбомное разрешение равное 960 x 640 превосходит в 1.5 раза ширину портретного базового разрешения равного 640 x 960, то вся компоновка в целом будет увеличена в 1.5 раза.

Компонент имеет свойство под названием Match, которое может принять значение равное 0 (ширина), 1 (высота) или любое значение лежащее в пределах между 0 и 1. По-умолчанию оно установлено в 0, что означает то, что текущая ширина экрана соответствует базовой ширине базового разрешения, о котором говорилось ранее.

Если свойство Match имеет значение не равное 0.5, оно будет сравнивать текущую ширину с базовой шириной, текущую высоту с базовой высотой, и выберет коэффициент масштаба близкий и к тому и к другому разрешению.

At this point the layout supports all the four screen resolutions using a combination of appropriate anchoring and the Canvas Scaler component on the Canvas.

Для более подробной информации о том, какими ещё способами можно добиться масштабирования элементов интерфейса относительно разных разрешений экрана, посетите страницу документации Canvas Scaler.

Начиная с версии 4.3 в Unity появилась возможность работы с 2D графикой, большая часть новых стандартных решений мне пришлись по душе, потому что я как раз незадолго до этого обновления перешел с Corona SDK.
Но что меня не порадовало, так это отсутствие стандартных инструментов для оптимизации спрайтов под разные разрешения экранов, что имеет довольно таки существенное влияние на производительность на маломощных устройствах.

Конечно, можно использовать что-то похожее на 2D Toolkit для решения этой проблемы, но зачем платить 75$ если можно сделать все самому?

Cо слов пользователей официального форума Unity, разработчики в скором времени не планируют расширять 2D функционал, по крайней мере до релиза 5 версии Unity, и пока что пользователи должны самостоятельно решать данную проблему. Бороздя просторы интернета в надежде найти ответ, я набрел на интересный доклад одного из разработчиков Unity на летней Nordic Game Conference 2014, название говорит само за себя «2D issues and how to solve them». Пользуясь материалами этого доклада, я сделал свое решение проблемы поддержки дисплеев разного разрешения.

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

Подготовка спрайтов

Итак, на первом этапе мы должны организовать атласы спрайтов для разных разрешений: SD, HD, ultra-HD, у нас же будут использованы суффиксы 1x, 2x, 4x.

Берем атлас спрайтов, в нашем случае это ’spritesheet1@4x.jpg', в инспекторе выбираем нужные параметры, режем атлас в Sprite Editor, если требуется. Создаем еще две копии атласа в Project Browser (cmd+D, ctrl+D) и переименуем их так, чтобы суффиксы в названии были '@2x', '@1x’, меняем свойство Max Size на значение в 2 и в 4 раза меньше соответственно.

Спрайты должны находится в папке Resources, если таковой не имеется — создайте. Это позволяет загружать файлы с этой папки во время выполнения программы.

Обращу Ваше внимание на поля Pixels Per Unit и Format, первое поможет подобрать размер спрайтов под размеры сцены без изменения scale, а второе является очень важным для правильной передачи цвета, размера билда и использования ресурсов графического процессора. На эту тему есть замечательный мануал

Подготовка префаба

Тут все просто, мы собираем игровой объект на основе атласа спрайтов с суффиксом ‘@2x’, добавляем анимацию и любые другие фишки, которые могут вам понадобится. Сохраняем объект как префаб.
Суффикс ‘@2x’ был выбран, потому что большая часть устройств имеют hd разрешение, нам не придется делать лишнюю работу в большинстве случаев.

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

Основной принцип работы скрипта таков: у нас есть публичная переменная spriteSheet, в которой мы передаем имя атласа, в котором находятся спрайты нашего объекта.

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

Потом в методе ManageQuality, имея данные о разрешении экрана, загружаем в массив sprites все спрайты нужного нам атласа с правильным суффиксом. В массив renderers загружаем все компоненты SpriteRenderer, которые находятся в объекте. Ищем в массиве sprites спрайт по имени и присваиваем его спрайту компонента SpriteRenderer, если такой существует. Завершает все Resources.UnloadUnusedAssets (), этот метод выгружает из памяти неиспользуемые ассеты.

Также этот скрипт можно использовать для изменения всех спрайтов в сцене. Для этого создаем новый объект, например SpriteManager, и добавляем к нему данный скрипт, но с измененным определением массива renderers:

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

Потому что на рынке много производителей мобильных телефонов и существует множество разрешений экрана. Разрешение (разрешение экрана) - это точность изображения на экране, которая относится к количеству пикселей, которые может отображать дисплей. Единицы разрешения следующие: (точка на дюйм на Дюймы), lpi (количество строк на дюйм) и ppi (пикселей на дюйм). Чем выше разрешение изображения, тем больше пикселей оно содержит, тем четче изображение и лучше качество печати.

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

Прежде всего, мы сначала понимаем Canvas (На самом деле это экран поддерживаемого устройства, настройте Game Разрешение в обзоре регулируется Canvas , То есть выбрать поддерживаемый размер экрана устройства) : Точнее Canvas При условии схемы масштабирования, то Набор разрешений должен быть определен как разрешение нашего дизайна, а затем соответствующим образом масштабирован на разных мобильных телефонах, чтобы гарантировать, что эффективная область контента нашей игры может отображаться на экране.

Схема адаптации экрана, предоставленная Unity

expand：

Этот метод будет увеличивать масштаб с меньшими значениями ширины и высоты, которые необходимо увеличить, так что направление, в котором коэффициент масштабирования больше, будет иметь недостаточный коэффициент масштабирования и черные границы. Нет картины и нет правды, давайте посмотрим на реальную ситуацию. Сначала посмотрите на нормальное разрешение (750 * 1336):

На картинке показано разрешение дизайна, давайте посмотрим на результат отображения на планшете:

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

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

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

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

3、Match Width Or Height

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

Какой метод использовать для экранной адаптации

Чтобы решить эту проблему, мы должны сначала подумать, какая часть нашей игры должна отображаться.Здесь мы представляем концепции эффективного игрового контента, фактического контента игры и недопустимого контента.

Из введения на приведенном выше рисунке мы видим, что после завершения разработки игры ее эффективное содержимое должно отображаться полностью независимо от того, какой мобильный телефон включен. Благодаря приведенному выше введению нескольких режимов мы можем обнаружить, что сжатие определенно обрезает игровой контент, а Match Width Or Height может также обрезать игровой контент.Только в режиме расширения будет отображаться весь контент, когда мы разрабатываем игру. , Итак, мы выбрали здесь расширенный режим для адаптации экрана.

Но теперь у меня есть другая проблема. В режиме расширения будут черные границы из-за недостаточного масштабирования в одном направлении. Здесь мы выбираем заполнение недопустимым содержимым. То есть границы с обеих сторон считаются недопустимым содержимым, как и на схематическом представлении. Если есть черные границы сверху и снизу, верхняя и нижняя границы будут обработаны. Этим достигается экранная адаптация. Наконец, взгляните на нормальную ситуацию отображения:

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

Об особом отношении к Лю Хайпину

Устройство Android

В Android API 28 добавлена обработка Liu Haiping. При упаковке выберите 28 API.

Черная рамка на рисунке - это строка состояния, которая не была сохранена при создании снимка экрана.

Первоначальная идея состоит в том, чтобы определить, является ли это Лю Хайпин, и, если это Лю Хайпин, переместить содержимое игры вниз.

Какие существуют способы сохранения эталонного изображения при запуске на разных форматах разрешения? Под "изображением" я подразумеваю в целом картину, наблюдаемую на экране, а не конкретно Image - т.е. и интерфейс, и объекты на сцене. Желаемый результат представляю примерно так:

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

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

411 1 1 золотой знак 4 4 серебряных знака 15 15 бронзовых знаков А чем anchors не подошли? Там довольно гибкая настройка. @trollingchar с помощью якорей, я могу зафиксировать интерфейс - это я знаю. А что делать с отображением объектов на сцене в таком случае?

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

Сначала скажу, что нам понадобится канва. Канва, когда ее создаешь, имеет компонент Canvas Scaler. Его ставим на Expand и указываем разрешение канвы. В моем примере это 1000 x 600. Там мы создадим 4 черных изображения (это будут наши черные полоски по краям, хотя мы можем сделать их и не черными, а даже с текстурой) и поставим такие свойства:

Результаты на разных разрешениях экрана:

Интерфейс мы будем под пустым объектом в канве, настроенным на выравнивание по центру и размер 1000 x 600. Важно: он должен идти до черных полосок, иначе когда часть интерфейса за них улезет, то ее будет видно.

Осталось настроить камеру. У меня в проекте это делает скрипт с такой строчкой в апдейте:

Можете теперь настроить zoom как вы обычно настраиваете у камеры orthographicSize . Однако, если проект в 3д, предположительно, надо менять Field of view, но точной формулы сказать не могу.

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

Делаем канву и черные полоски по аналогии. Создаем RenderTexture, ставим ей нужное нам разрешение. Камер у нас будет две, одна отрисовывает объекты сцены на текстуру, другая показывает канву с черными полосками и нашей текстурой. Текстуру отображаем при помощи RawImage, якоря по центру, размеры 1000 x 600. У той камеры, которая снимает мир, убираем UI из маски, второй камере наоборот ставим только UI. И добавляем интерфейс в дочерние объекты этой текстуры.

Недостатки этого метода в том, что качество картинки может потеряться, если разрешение поставить слишком большое - будут видны большие размытые пиксели, а у интерфейса будет все нормально с этим. Частично это решается установкой в 2 раза большего разрешения - 2000 x 1200. И еще недостаток это то что надо возиться с камерами и слоями.

Читайте также: