Чи нормально в грі використовувати 100% процесор?

Я щойно реалізував багатопотокове керування входом у своєму ігровому двигуні, де код, який опитує ОС для збору вхідних даних від неї та часових позначок, знаходиться в окремому потоці, і кожен кадр у головному потоці я просто з'їдаю зібраний вхід до логічний ігровий час. Це все працює, але ця настройка використовує 100% мого процесора. У мене є два ядра, і це відбувається до 100% під час роботи моєї гри.

Я перевірив інші ігри, щоб перевірити, чи роблять вони це теж. Наприклад, Skyrim і Doom 3 здаються непоганими з процесором трохи більше 60%.

Чи прийнятно для гри, яка використовує багатопотоковий вхід, щоб використовувати до 100% ЦП? Якщо ні, то якими трюками користуються такі ігри, щоб знизити використання процесора вхідним потоком?

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

У вашому випадку - Ні, це виглядає як неефективна конструкція, взяти нитку і зробити її опитуванням на події в циклі ( while true do CheckForEvents;). Виправте мене, якщо я помиляюся, але ОС вже опитує події. Ви повинні просто перевірити їх у головному потоці раз на кожен галочку.

Основний цикл гри повинен бути досить швидким для запуску 30+ кліщів в секунду, що цілком достатньо для опитування команд для багатьох ігор. Гравець не побачить різниці, якщо його команди будуть оброблені, наприклад, 0-33ms пізніше. З іншого боку, ви могли б використовувати це додаткове ядро ​​процесора для більш вигідних завдань, таких як МНОГО кращий штучний інтелект чи фізика чи що завгодно.

PS Як вимагається уточнити в коментарях, не приймайте вище номерів сліпо для всіх видів ігор. У той час як для гри TBS може знадобитися лише 1 галочка за поворот, а гра RTS може бути чудовою з 10 кліщами за поворот, інші жанри, як RaceSims, потребують значно більше. І звичайно не пов'язуйте логічні кліщі з частотою кадрів, це дві окремі речі.

Гра з постійним активним оновленням вікон в основному працюватиме в повноекранному режимі і буде єдиною (великою) програмою машини, якою керує ОС. Тому цілком прийнятно використовувати 100% процесора, тому що нічого іншого йому не потрібно.

Однак це не означає, що, звичайно, завжди потрібно використовувати 100% незалежно від стану гри. Більшість ігрових циклів використовують режим сну як роздільник рамки, якщо вони закінчили виводити кадр перед обмеженням частоти кадрів, щоб не використовувати процесор дарма.
Це, мабуть, те, що відбувається у ваших прикладах: ваш апарат швидше, ніж Skyrim або Doom 3 потрібно запустити, тому вони використовують лише те, що потрібно - але все те, що їм потрібно.

Як сказав @KromSterm, ОС зазвичай вже опитує події для вас, тому немає необхідності робити цикл швидше, ніж у ОС. Якщо у вас є лише два ядра, використовувати 100% другого лише для виявлення подій - це не дуже гарна ідея, тому що якщо ви переносите події лише в основний цикл оновлення, це дуже швидко виконати. Спробуйте використати це ядро ​​для частини основного завдання замість іншого потоку.

Є кілька недоліків, спрямованих на використання всього доступного часу процесора в ПК або мобільній грі.

Системні вимоги: Якщо гра може бути відтворена на ПК, де ви розвиваєте свою гру, вона може бути відтворена на слабшому ПК, який належить тому, хто придбав вашу гру. Обмеження використання процесора дозволить утримувати гру, придатну для використання на машинах, на яких, швидше за все, вже є люди. Якщо ви дійсно хочете дізнатися, чи обмежуєте ви свій ринок, протестуйте свої ПК на комп’ютері та ігри своїх конкурентів на роз'єм Atom, який працює на трансформаторі, як-от Transformer Book, або протестуйте свої мобільні ігри на недорогий передплачений телефон Android.

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

Змінність фізики: Якщо фізика, яка впливає на геймплей, буде більш детальною на сильніших машинах, однакові дії гравця матимуть різні результати на різних машинах. Це означає, що гравець, можливо, зможе обдурити, використовуючи більш сильну або слабку машину. Quake III Arena Id відомий тим, що частота кадрів впливає на висоту стрибка . Щоб цього уникнути, багато ігор використовують фіксований крок часу з фізики. Але це не впливає на фізику, відключену від геймплея, наприклад, ефект частинок або ефект тканини або інтерполяція координат між фізичними кадрами для відтворення відео з більшою швидкістю кадрів, ніж фізика. Тож спроектуйте свою фізику, використовуючи якийсь варіант модельного перегляду-контролера архітектура, де необхідні речі (прискорення, виявлення ударів тощо) входять у модель, і цукерки для очей, що регулюються, переглядаються.

Мінливість AI: Якщо AI буде детальніше на сильніших машинах, вороги поводяться по-різному на різних машинах. Наприклад, у реалізації Go або Chess супротивник буде слабшим на слабшому ПК, і гравці можуть обманювати, граючи в гру на слабшому ПК або запускаючи фонові процеси, такі як антивірусне чи перекодування відео чи оновлення операційної системи.