Розробники NS2 Якість FPS - або - Чому 90fps відчуваються як 30
Напередодні виходу 267-го білда, вирішив перевести повідомлення одного з CDT-розробників NS2 (matso [forums.unknownworlds.com]) на форумі UWE, який розповів про знайдені проблеми та шляхи їх вирішення в движку NS2.
Однією із завдань для білда 267 було знаходження причини чому в NS2 дуже низька якість часу кадру (frame-time) або «Чому 90 fps відчуваються як 30». Виявилося, що цьому є кілька причин. Розглянемо їх послідовно.
Другою проблемою є те, що менеджер текстур використовує драйвер у той же час, коли головний рендер-потік (render thread) – щось рендерит. Так як рендер-потік є «вузьким шийкою», це означає, що менеджер текстур гальмує весь процес рендерингу. поки що йде процес рендерингу. Це в свою чергу означає, що менеджер текстур не зможе швидко завантажити потрібні текстури, тому іноді ви будете бачити ті самі low-res текстури частіше, але ...
Далі йтиметься про такий параметр, що впливає на час кадру, як недосконала підготовка ассетів (або наборів, asset setup). т.д.) були завантажені і скомпільовані/підготовлені перш, ніж ви почнете грати, тому якщо вам потрібен певний ассет, коли програма на критичному шляху (тобто працює над наступним кадром), то він миттєво доступний.Це те, чим займається NS2 під час довгої фази Завантаження/Кешування (Loading/Precaching). Ну, чи, мав займатися.Коли я дивився на стрибкоподібний “p_logall” лог у PerfAnalyzer'і, я побачив, що є безліч записів “File::Open lingering in the neighbourhood”. На жаль,не можна було побачити який саме файл це викликав.
Як тільки я отримав доступ до движка NS2, я додав логування "file critical path", тобто. тепер, коли файлова система перебувала в стані «критичного шляху», вона могла логувати файли, які відкривала (занадто багато файлів відкривалося під час «некритичного шляху», той самий текстурний менеджер вантажив текстури, тому логувати всі звернення до файлів було надто напружено).
Подивившись логи, виявилося, що занадто багато звернень до файлів посилалися на неправильні місця, і цьому було безліч причин.
-Шрифтивідкривалися на вимогу, і Менеджер Шрифтів відстежував використання шрифтів і закривав їх, коли використання скорочувалося до нуля. . ви отримуєте затримку, поки шрифт завантажується з файлової системи і компілюється, ця затримка складає в середньому 5-10мс. Потім елемент зникає з екрана… і Менеджер Шрифтів закриває шрифт, що не використовується, готуючи вас до чергової затримки в 5-10мс, коли знову з'явиться елемент, що вимагає даний шрифт.
-Матеріали– маленькі файли приблизно 100 байт. Вони вважалися надто маленькими, щоб їх кешувати… що прийнятно, якщо вони знаходяться у буфері файлової системи або на SSD, але якщо ні – готуйтеся до 5-20мс затримки на кожен файл.
-Кінематики (Cinematics)– типу фільмів, що містять звуки, моделі (з матеріалами та текстурами) та скрипт. Їх безліч у грі, починаючи від водоспадів і закінчуючи пострілами рейлгана. Виявилося, що Кінематики кешували тільки свої текстури. І нічого більше. Це означає, що коли Кінематика вперше грає для вас, вона починає компілювати моделі,яких ще не було. Перед компіляцією, вона спочатку їх завантажує з файлової системи… І кінематика може містити до 20 моделей. А моделям потрібен час на компіляцію… Здрасти, затримка в 100+ мс.
Кінематики контролюють такі речі як ефекти млинця, криваві відбитки тощо. Вгадайте, що відбувається, коли ви вперше потрапляєте у заварушку, або зустрічаєте нового алієну, або гармату у морпіха.
-Графічний інтерфейс (GUI)використовується для відображення HUD, і він дивний. Весь lua-код завантажується, коли запускається клієнт, але код GUI завантажується на вимогу. Тому вперше стаючи джетпакером, або Екзо, або алієном, скрипт GUI компілюється.
Не критично, одинарний лаг при мутації в нову форму алієну - особливо не напружує. Тим не менш, це дуже погано взаємодіє з процесом кешування речей в NS2. Ви кешуєте потрібні вам асети на етапі їх компіляції, також, при завантаженні lua-коду, клієнту NS2 повідомляється які асети йому потрібні. даний час, т.к. система кешування не повинна бути використана вже під час гри, інакше це зовсім ніяке не кешування. щоб закладати черговий кадр.
-Ще каламутніша річ ніж система GUI, цепідсистема GUI звана GUIViews. Вона дозволяє вам малювати поверх текстур, і спочатку була реалізована через віртуальну машину Flash. Впроваджувати Flash для того, щоб повідомити скільки набоїв залишилося в обоймі, досить дурна витівка, тому Flash був замінений на віртуальну машину Lua (Lua VM).а індивідуальною Lua VM. Одна віртуальна машина на кожному дисплеї. Тому звичайний морпіх мав одну окрему Lua VM для дисплея автомата і ще одну для пістолетного дисплея. Так, ще одну для дисплея будівельного інструменту. Ну і одну для велдера, якщо він у нього був.
Все не так вже й погано, як вам здається, Lua VM – маленькі та дешеві (у плані ресурсів). Проблема полягає в тому, що дисплеї динамічно створюються та знищуються. Ось, кинули ви автомат – Lua VM знищено. Підняли ви автомат – і нова Lua VM створюється, підвантажує свій код… з файлової системи. 2>Тепер ви знаєте, чому піднімаючи ваш перший шотган у сьогоднішній грі ви завмираєте на 100+ мс.
======= У будь-якому випадку, більшість цих речей (найкритичніші) будуть виправлені в 267 білді, що додасть гладкості геймплею. Інше буде пофіксовано в 268 білді.