Подтвердить что ты не робот

Множественные разрешения экрана/пропорции (игры)

EDIT: Спасибо за ваши ответы и комментарии. Подумав об этом, я бы перефразировал суть вопроса: "Как определить и ограничить минимальное разрешение/соотношение, которое может сыграть моя игра". Так как имо или игра становится неиграбельной на самом маленьком экране/соотношении (отсутствие деталей) или поддерживая даже самый маленький экран/соотношение, значительно ухудшает опыт для всех остальных. Кроме того, мы даже не знаем, что такое наименьшее разрешение или оно может каким-либо образом его ограничить, кроме отключения ldpi... которое все еще не говорит нам о самом маленьком mdpi. В конце концов, я не думаю о том, как создать хороший результат, но о том, как создать идеальный результат;). Угадайте, что это невозможно (еще?).

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

Я всегда находил определения того, какие решения ожидать несколько неопределенно. Я знаю список в документах.

Теперь мой первый вопрос заключается в том, является ли этот список полным или, другими словами, производителю разрешено использовать другие коэффициенты или пропорции. Мой текущий подход заключается в просмотре этого списка с точки зрения соотношения сторон, который выглядит примерно так (не уверен, если он точно, но вы получите идею):

  • ldpi: наименьшее соотношение сторон 4: 3
  • mdpi: наименьшее соотношение сторон 3: 2
  • hdpi: наибольшее соотношение сторон 16: 9

4:33:216:9

Итак, если я хочу охватить целый ряд устройств, я выясню, каковы мои самые маленькие и мои самые большие пропорции, а также дизайн макета для самого маленького, и при этом он автоматически растет до самого большого. Например, если я хочу поддерживать все плотности, я проектирую экраны на 4: 3 и увеличиваю их до 16: 9. В случае, если я удалю поддержку ldpi, я бы разработал для 3: 2. Конечно, это предполагает, что никогда не будет устройства mdpi с соотношением сторон 4: 3, которое вернет нас к моему первому вопросу.

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

Есть ли у кого-то лучший подход? (Имейте ввиду, что это только для игр на телефонах)

4b9b3361

Ответ 1

Я нашел ясный ответ на эту проблему.

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

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

  • xlarge экраны не менее 960dp x 720dp
  • большие экраны не менее 640dp x 480dp
  • обычные экраны не менее 470dp x 320dp
  • маленькие экраны не менее 426dp x 320dp

Примечание.. Эти минимальные размеры экрана были не так четко определены до Android 3.0, поэтому вы можете столкнуться с некоторыми устройствами, которые неправильно классифицируются между нормальным и большим. Они также основаны на физическом разрешение экрана, поэтому может варьироваться в зависимости от устройства - например, Планшет с разрешением 1024x720 с системной панелью на самом деле имеет немного меньше места доступный для приложения из-за того, что он используется системной панелью.

Источник

Ответ 2

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

Ответ 3

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

Чтобы быть откровенно, и я надеюсь, что я не единственный, но в полной мере использую DIP (независимые от устройства пиксели) и относительную компоновку и такие... уменьшил мои файлы макета активности до 1 на активность, а не 3 различных типа для HDPI, MDPI и LDPI.

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

Display display = getWindowManager().getDefaultDisplay();  int displayWidth = display.getWidth();  int displayHeight = display.getHeight();

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

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

может быть объяснено немного загадочным, но главное, чтобы преодолеть различные разрешения устройства, - это много работать с:

  • relativelayouts
  • Независимые от устройства пиксели

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

может быть, глупый пример, но эй, это сработало для меня:-) здесь ниже я попытался получить размер текста в текстовом виде относительно относительно одного на всех устройствах. Вы можете вызвать класс "TypedValue" и выбрать один из множества общедоступных переменных, предлагаемых там. Поскольку я хотел, чтобы TextView везде одинакового относительного размера, я использовал следующий код:

someTextView.setTextSize(TypedValue.COMPLEX_UNIT_DIP, 18);

следует указать, насколько велика величина в DIP. TypedValue может использоваться во многих компонентах виджета или активности, для которых требуется значение INT для свойств размеров. Играйте с этим, и вы увидите, что жизнь намного проще: -p

надеюсь, что этот ответ поможет немного

Ответ 4

Нет исчерпывающего списка пропорций. Производители могут решить, какое решение они хотят. Кроме того, соотношение сторон не соответствует плотности пикселей, поэтому использование ldpi/mdpi/hdpi для определения соотношения сторон, вероятно, не очень хорошая идея.

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

Ответ 6

Вы можете ограничить, какие устройства могут видеть вашу игру на рынке по разрешению экрана: http://developer.android.com/guide/appendix/market-filters.html

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

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

Здесь больше информации о поддержке размеров экрана: http://developer.android.com/guide/practices/screens_support.html

: D