Разные разрешения экранов на разных устройствах

[tooth212]

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

[Astraport]

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

Изменяется ли качество изображения, если оно векторное, но размер не подобран?

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

[caseyryan]

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

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

Main.SCALING = stage.fullScreenWidth / 1024;

То есть если экран устройства 800х480, к примеру, то скейлинг получится 800 / 1024 = 0,78125;
Потом просто scaleX и scaleY всей нужной графики умножаю на полученную величину, и получаю графику в нужном масштабе.

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

[tooth212]

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

[caseyryan]

Какая разница анимация там или просто векторные картинки. Процессору одинаково сложно это просчитывать

[tooth212]

Спасибо.

[morgenshtern]

Multi-Resolution Development
http://wiki.starling-framework.org/m...on_development

[caseyryan]

Сообщение от morgenshtern

Multi-Resolution Development
http://wiki.starling-framework.org/m...on_development

Это хрень. Сомневаюсь даже, что они сами так делают. Такой подход очень не гибкий.

[morgenshtern]

Это охрененно. Гибко, просто, быстро.
А где ссылка/описание лучшего подход, кстати? Та фигня что вы предложили, про скейл, что ли?

[caseyryan]

Сообщение от morgenshtern

Это охрененно. Гибко, просто, быстро.

Ок, ситуация: есть разные разрешения экранов на андроиде, особенно китайцы пестрят этим. Вот что если разница в размере экранов не ~2 раза, а 1.2. Или размер экрана на одном 800х480, а на втором 960x720, на третьем 640x480. Получится что для них используется один и тот же scale factor. При таком подходе часть элементов может просто не поместиться на экране, или некрасиво съехать куда-то в сторону. И на другую графику заменить нельзя, потому что она там в два раза больше. Получается что нужно заэмбэдить кучу картинок под самые разные разрешения. При этом значительно возрастет объем файла приложения и появится куча строк [Embed] и классов для них. И вероятнее всего художник не будет рисовать графику отдельнго под каждое разрешение. То есть получится тот же самый скейл, только заранее. Этот подход хорош только в том случае, если есть параноидальное стремление к сверхчеткости изображения на всех экранах (что для игр в большинстве случаев вообще роли не играет)

Так чем это
1) гибко?
2) просто?
3) быстро?
Есть аргументы?


Программный скейл (из большего в меньший размер, естественно), однозначно быстрее, проще, и гибче. Он позволяет получить что-то вроде density independent pixel (а это тоже не последнее дело, плотность пикселей у всех разная). Позволяет сохранить относительно небольшой объем файла. Позволяет проще править графику, если в ней нужны какие-то дороботки.