Яку систему координат використовувати для обробки 2D інтерфейсу?

Виходячи з питання про співвідношення сторін , мені цікаво почути, чим користуються інші люди, працюючи над 2D системами інтерфейсу користувача (швидше за все, своїми власними рішеннями для дому). Зокрема, як поводитися з системами координат. На мій погляд, є три варіанти:

1. Жорстко кодовані координати (наприклад: 0 -> 720, 0 -> 576)
2. Нормалізовані координати (0,0 -> 1,0, 0,0 -> 1,0), відображені в реальні координати перед візуалізацією
3. Віртуальні координати (наприклад: 0 -> 1600, 0 -> 1000), відображені в реальні координати перед візуалізацією

Жорстко закодований, очевидно, корисний лише в тому випадку, якщо ви знаходитесь на встановленій платформі і знаєте, які координати вашого екранного простору заздалегідь, або якщо ви готові створити макети екрану для всіх можливих наборів розмірів екрана.

Нормалізовані координати є приємними, але страждають від неоднозначності, коли співвідношення сторін екрана не фіксовано (наприклад, 0,75 відображає іншу фізичну координату при запуску на широкоекранному, ніж це у 4: 3). Крім того, для авторів, дійсно контрпридатним оголошувати елемент інтерфейсу таким, що є (0,2 x 0,2), лише виявити, що він насправді не квадратний під час надання.

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

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

Ми працювали з підходом до віртуальної координації, зокрема, щоб уникнути неоднозначності щодо співвідношення сторін. Так, при візуалізації на екрані 16:10, простір інтерфейсу користувача дорівнює (0,0) -> (1600,1000), але при візуалізації в 4: 3, корисний простір інтерфейсу є фактично (133,0) -> (1467 , 0).

Чи є кращі рішення, про які я просто не знаю? Чи є якісь стратегії мінімізації проблем, які мають ці три підходи?

Я думаю, що я згоден, що нормалізовані координати насправді не відображають вміст інтерфейсу користувача.

Те, що я зазвичай роблю для двовимірних макетів, в основному є вашим "віртуальним" координатним простором, але я вибираю простір, який відображає 1: 1 з моїм кращим цільовим дозволом (наприклад, 1280x720). Це не виправлено, але з цим зрозуміти інтуїтивно, і я знаю, що в 90% випадків це буде виглядати цілком правильно. Очевидно, важливо не проявляти самовдоволення і часто перевіряти різні резолюції.

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

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

Система координат CEGUI здається дійсно продуманою. Це єдина система координат сумішей абсолютного позиціонування з відносним позиціонуванням. Ви можете вказати місця, наприклад:

• посередині екрана
  UDim(0.5,0)
• п'ять пікселів зліва від правого краю
  UDim(1.0,-5)
• два віджети посередині, але розділені на 10 пікселів
  HA_RIGHT,UDim(0.5,-5) HA_LEFT,UDim(0.5,5)

Якщо ви сумніваєтесь, чому б не піти з моделлю коробки CSS або спростити її?

Ви можете вказати позиції у відсотках або пікселях. Ви можете розміщувати контейнери у відсотках, але позиціонувати елементи, наприклад, у пікселях.

Мені подобається використовувати віртуальні координати, але засновані на загальній цільовій роздільній здатності (бажано, одній з найвищих роздільних можливостей, на яку ви очікуєте, що гра буде запущена.

У наші дні хорошим вибором може бути 1920x1080.

Усі твори ілюстрації та макети екрану можуть бути створені з такою роздільною здатністю, і це дозволяє легко вимірювати положення / відстані в пікселях.

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

Під час кодування я вважаю, що "мислення в пікселях" набагато простіше, ніж мислення в нормалізованих координатах! - Я хочу, щоб текст був "50 (віртуальних) пікселів у висоту", а не "0,0463 одиниці висотою"

Це повністю залежить від того, який тип графічного інтерфейсу у вас є, але часто в іграх є прикріплені речі по краях екрана та в кутах, і тоді вони можуть мати поле посередині екрана для модального діалогу чи щось подібне.

Якщо це стосується вас, то чи можу я запропонувати використовувати схему, де ви вказуєте якір і зсув (x, y)? Це буде схоже на Java BorderLayout (але, можливо, з чотирма кутами, чотирма середніми краями та одним центром екрана). Так, наприклад, ви можете вказати зміщення (0,0) у верхньому лівому куті; тоді елемент буде закріплений саме в куті екрана. І тоді, незалежно від того, яка роздільна здатність, співвідношення сторін тощо, у кутку екрана з'явиться показник стану здоров'я. Але тоді, якщо прив’язувати елемент до правого верхнього кута, елемент, природно, буде закріплений відносно його правої верхньої точки (замість верхнього лівого пункту), тож він знову буде автоматично прив’язаний до кута екрана, незалежно від роздільної здатності.

Я напевно рекомендую проти нормалізованих координат 0,0-1,0; вони можуть змінюватися залежно від точності з плаваючою комою. Графічні інтерфейси повинні бути відображені в пікселях, якщо у вас немає 3D-інтерфейсу.

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