Як ви підходите до незалежності дозволу в растровому графічному вмісті?

Ті ігри, яким не пощастило запускатись на специфікованій блокованій платформі, як, наприклад, портативні пристрої, повинні працювати в різних форматах роздільної здатності та співвідношенні сторін.

У 3D-грі ви можете мати HUD або графічний інтерфейс меню, заснований на растровій графіці, а в 2-грі у вас може бути купа квадроциклів, які є судинами для спрайтів.

Отже, моє запитання полягає в тому, як ви підходите до розробки та керування вмістом у різних роздільних здатностях та співвідношенні сторін? Припустимо, у вас є спрайт-символ, що має спрайт 300x400 пікселів і оточений рівнем з плиток. У різних співвідношеннях роздільної здатності / співвідношення сторін ви взагалі бачите інший FOV. Або якщо у вас є HUD або меню GUI, ви хочете, щоб деякі елементи зберігалися в одних і тих же розмірах щодо екрана. Проте джерело графіки - растрові растрові карти, а не векторні.

Очевидно, що проблема вирішувалась неодноразово. Мені цікаво почути різні підходи, які досі працювали для вас. Чи зберігаєте ви довільну розмірність агностичного "пікселя", яку ви магічно перетворюєте на потрібні розміри за допомогою формули, заснованої на співвідношенні res та size або інших підходах?

редагувати:

Отже, висновок - перерахувати співвідношення сторін. Найнижча комбінація аспектів: роздільна здатність - це те, для чого ви розробляєте важливі речі. Безпечна зона, якщо ви хочете. Те саме співвідношення сторін, але більш висока роздільна здатність є простими проблемами масштабування. Арт-контент розроблений для максимальної роздільної здатності. Більші співвідношення сторін просто показують більше рівня / FOV з поданою інформацією, яка не є критичною, як і в безпечній зоні. Щось на зразок цього зображення я зробив .

Якщо ваші роздільні здатності схожі між собою, ви можете просто використовувати одне й те саме мистецтво для всіх, можливо, деякі скорочення часу зменшення для менших екранів. Якщо вони відрізняються більше, ніж скажімо, коефіцієнт у 2 рази, вам потрібно буде написати (або принаймні налаштувати виконавця) окремі ресурси для різних роздільних можливостей.

Завдяки 2D, роздільна здатність має величезний вплив на те, як ви створюєте зображення. Спрайт, який виглядає детально та реалістично на високій роздільній здатності, буде каламутним і нерозбірливим, зменшеним. Крім того, спрайт-спрайт з чітким і чітким поглядом на низьку роздільну здатність буде виглядати дешево і надмірно просто у високій роздільній здатності.

Одним із способів є створення активів зображення у векторіальному форматі (SVG, Illustrator тощо) та перетворення їх у растрові зображення за потребою різних версій гри.

Якщо ви підтримуєте повноекранний екран із різною роздільною здатністю, якщо ви хочете вдосконалення пікселів (тобто "Так, як це створив художник"), проблема полягає в тому, що не існує повністю автоматизованого способу масштабування спрайтів вгору АБО вниз (або їх обертання), що не відповідає " t не потребує схвалення людини. Зрештою, це тому, що розміщення пікселів - це суб'єктивна річ. Алгоритм візуалізації виконує деяке масштабування або обертання, і для цього необхідно використовувати деякі методи наближення, наприклад. білінеарне фільтрування. Якщо ви все ще хочете жорстких країв пікселів для того, щоб мати "досконалість пікселів" (тобто не використовувати AA або BF), вам доведеться прийняти, що масштабування на деякий ступінь потужності 2 ступеня не буде в виробляти деякі небажані артефакти.

Цікавий підхід до подібної проблеми є у RotSprite , застосуванні / алгоритмі, призначених виконувати "автоматичні" обертання спрайтів. Маючи на увазі, я маю на увазі, що це дає ряд можливих бажаних кінцевих результатів після інтенсивної обробки, з яких людський оператор може вибрати. Тоді підібрані власноруч спрати вступають у гру, тобто це крок створення вмісту, а не час виконання.

Один з можливих відповідей на ваше запитання про "довільний піксельний агістичний піксель": OpenGL (який ви, можливо, збираєтесь використовувати, якщо ви збираєтеся крос-платформний), працює абсолютно іншим чином, ніж програмний растровий рендерінг. Він враховує ширину та висоту дисплея в діапазоні з плаваючою комою 0,0-> 1,0 і відповідно відображає пікселі на графічному процесорі. Звичайно, це може призвести до артефактування, якщо, наприклад, Для текстур увімкнено BF (це те, що ваші спрайти у OpenGL).