Як зробити систему незалежної роздільної здатності?


10

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

Чи існує справжній і перевірений підхід до цього? Програвачі відео показують чорні межі через цю проблему, чи це неправильно вирішити?


1
Дивіться [це] [1] питання. Моя відповідь пояснює деякі деталі горі. [1]: gamedev.stackexchange.com/questions/34/…
інженер

Відповіді:


5

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

Однак, є кілька кроків до створення надійної незалежної від растрової системи розв'язання: розмір, системи координат та компонування.

Для розміщення та розміщення нам потрібно використовувати деякий набір одиниць, які підтримують відношення до фактичної роздільної здатності програми. У цьому випадку давайте використовувати дюйми, тому що я американський, і ви можете масштабувати елементи за допомогою DPI (крапки на дюйм). Наприклад, скажімо, що ваша програма працює в 800x600. За замовчуванням Windows DPI становить 96, так що програма має роздільну здатність (800/96) x (600/96) дюймів або 8,33x6,25 дюйма.

Оскільки вам потрібно вміти працювати, принаймні, із співвідношенням сторін 4: 3 та 16: 9, як ви керуєте своєю системою координат екрану, стає дещо складним. Те, що я рекомендую робити, - це поставити (0,0) в центр області дисплея (а також вікна та елементи керування). Це добре працює, тому що якщо ви помістите (0,0) у кут, тоді, коли цей кут рухатиметься навколо, залежно від роздільної здатності та співвідношення сторін, він перекладе всі ваші спрайти, тоді як центр екрану завжди буде центром екрана. Незалежно від пристрою. Продовжуючи наш приклад з 800x600, це призведе до системи координат, яка (зліва направо) від 4,165 дюйма до 4,165 дюйма і (зверху вниз) від 3,125 дюйма до -3,125 дюйма.

Отже, на даний момент у вас є DPI-незалежна система інтерфейсу з елементами, які завжди будуть знаходитись на одному місці відносно центру екрана - не зовсім роздільна здатність. На щастя, незалежність DPI дозволяє вам масштабувати інтерфейс користувача шляхом масштабування DPI на основі евристики. Наприклад, ми можемо масштабувати DPI, використовуючи вертикальну роздільну здатність як нашу евристичну. Якщо 800x600 становить 96 DPI, тоді ми будемо використовувати 123 DPI для 1024x768 або 115 DPI для 1280x720.

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

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


-1

Зазвичай те, що ви хочете зробити, залежить від гри.

Один із варіантів - мати чорні рамки, якщо співвідношення сторін (пропорція) відрізняється (можливо, найпростіше, просто візуалізуйте текстуру, а потім виведіть її на екран, змінивши розмір відповідно).

Інший варіант - мати різні контури візуалізації для різних співвідношень сторін. Ви можете мати один для широкоекранного, один для "нормального".

Ще один варіант - масштабувати речі окремо, наприклад, зробіть поле повідомлень інтерфейсу користувача більшим чи меншим, залежно від роздільної здатності. Кожен раз, коли вам потрібно розібратися, куди звернути, замість точних пікселів виконайте такі дії, як 0,2 вниз, 0,8 поперек, ширина 0,1, висота 0,3. У цьому випадку типово будеш розтягувати речі, хоча залежно від того, як ти малюєш речі, які можуть бути добре (тобто розтягувати фон інтерфейсу користувача, але не текст).

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


"просто нанесіть текстуру, потім виведіть її на екран, змінивши розмір відповідно" Ні. Це створило б дійсно розмите і дивно виглядає зображення. А що робити, якщо дозвіл занадто низький? Все стане нечитабельним.
Тара

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

Я читав. Але ваша відповідь дуже не визначена. Також ви неодмінно отримаєте описані мною проблеми, оскільки ви не можете просто зробити все низькою роздільною здатністю і очікуєте, що текст залишиться ідеально читабельним.
Тара

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

Я також не сказав рендерувати з меншою роздільною здатністю, ніж цільова. Ви просто не можете прийняти користувальницький інтерфейс 1: 1 і вивести його на меншу роздільну здатність, ніж це було розроблено (саме це я мав на увазі з меншою роздільною здатністю).
Тара
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.