Как вы подходите к независимости от разрешения в растровом графическом контенте?

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

В 3D-игре у вас может быть HUD или графический интерфейс меню, основанный на растровой графике, а в 2D-игре у вас может быть набор квадов, которые являются судами для спрайтов.

Итак, мой вопрос: как вы подходите к проектированию и управлению контентом в различных разрешениях и пропорциях? Предположим, у вас есть спрайт-символ со спрайтом 300x400 пикселей, окруженный уровнем, составленным из плиток. На разных разрешениях / соотношениях сторон вы могли бы видеть разные поля зрения. Или, если у вас есть HUD или меню с графическим интерфейсом, вы бы хотели, чтобы некоторые вещи были в тех же позициях и одинакового размера относительно экрана. Тем не менее, источником графики являются растровые растровые изображения, а не векторные.

Очевидно, проблема решалась много раз. Мне интересно услышать о различных подходах, которые работали для вас до сих пор. Сохраняете ли вы произвольную размерную единицу «пикселя», которую вы волшебным образом преобразуете в необходимые измерения с помощью формулы, основанной на разрешении и соотношении сторон или других подходах?

редактировать:

Итак, вывод состоит в том, чтобы перечислить ваши пропорции. Самая низкая комбинация аспекта: разрешение - это тот, в который вы вносите важные вещи. Безопасный район, если хотите. Те же пропорции, но более высокое разрешение - это простые проблемы масштабирования. Арт-контент рассчитан на высокое разрешение. Большие соотношения сторон просто показывают больше уровня / FOV с представленной информацией, которая не является критичной, как в безопасной области. Нечто подобное на этом изображении я сделал .

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

Благодаря 2D разрешение очень сильно влияет на дизайн изображений. Спрайт, который выглядит очень детально и реалистично в высоком разрешении, будет мутным и непонятным, уменьшенным. Аналогично, чистый и резкий спрайт в низком разрешении будет выглядеть дешевым и слишком простым в высоком разрешении.

One way is to make the image assets in a vectorial format (SVG, Illustrator, etc) and convert them into raster images as needed by the different versions of the game.

When maintaining fullscreen across different resolutions, if you want pixel-perfection (i.e. "As the artist produced it"), then the problem is that there is no fully automated way to scale sprites up OR down (or to rotate them) that doesn't require human approval. Ultimately that's because the placement of pixels is a subjective thing. The rendering algorithm performs some scaling, or rotation, and has to use some approximation techniques to do this, eg. bilinear filtering. If you still want hard edges on the pixels in order to have that "pixel perfection" (i.e. not using AA or BF), then you are going to have to accept that scaling by some non-power-of-2 degree is going to produce some undesirable artifacting.

An interesting approach to a similar problem is found in RotSprite, an application/algorithm designed to perform "automatic" rotations of sprites. By that, I mean it produces a number of possibly desirable end results after intensive processing, for the human operator to pick from. The hand-picked sprites then end up going into the game, meaning this is a content creation step, and not a runtime one.

One possible answer to your "arbitrary magical dimension agnostic pixel" question: OpenGL (which you may well be intending to use if you're going cross-platform) works in a totally different way from a software raster renderer. It considers the width and height of the display in floating-point range 0.0->1.0, and maps pixels accordingly on the GPU. Of course this can itself result in artifacting, unless eg. BF is turned on for textures (which is what your sprites are in OpenGL).