NS2 Developers Качество на FPS - Или - Защо 90fps се чувстват като 30
В очакване на пускането на 267-ата компилация реших да преведа съобщенията на един от разработчиците на NS2 CDT (matso [forums.unknownworlds.com] ) във форума на UWE, който разказа за откритите проблеми и как да ги разреши в двигателя NS2.
Едно от предизвикателствата пред компилация 267 беше да се открие причината, поради която NS2 има много ниско качество на кадрите или „Защо 90 fps се чувстват като 30“. Оказа се, че има няколко причини за това. Нека ги разгледаме последователно.
Вторият проблем е, че мениджърът на текстурите използва драйвера в същото време, когато основната нишка за изобразяване изобразява нещо. Тъй като нишката за рендиране е тясно място, това означава, чемениджърът на текстурите забавя целия процес на рендиране.Поправката е лесна, просто добавете флаг, за да накара нишката за рендиране да каже на мениджъра на текстурите да изчака, докато процесът на рендиране е в ход. Това от своя страна означава, че мениджърът на текстурите няма да може да зареди желаните текстури толкова бързо, така че понякога ще виждате същите текстури с ниска разделителна способност по-често, но ...
След това ще говорим за такъв параметър, който влияе върху времето за кадър като несъвършена подготовка на активи (или комплекти, настройка на активи). Необходимо е всички активи (модели, текстури, анимации, шрифтове, звуци, материали, шейдъри и т.н.) да бъдат заредени и компилирани/подготвени, преди да започнете да играете, така че ако имате нужда от определен актив, когато програмата е на критичния път (т.е. работи над следващия кадър), тогава той е незабавно достъпен .Това прави NS2 по време на дългата фаза на зареждане/предварително кеширане. Е, или трябваше.Когато погледнах скачащия „p_logall“ регистрационен файл в PerfAnalyzer, видях, че има много записи „File::Open lingering in the neighborhood“. За жалост,нямаше начин да се види кой файл го причинява.
След като получих достъп до NS2 двигателя, добавих регистриране на „файлов критичен път“, т.е. сега, когато файловата система беше в състояние на "критичен път", тя можеше да регистрира файловете, които отвори (прекалено много файлове бяха отворени по време на "НЕкритичния път", същият мениджър на текстури зареждаше текстури, така че регистрирането на всички достъпи до файлове беше твърде стресиращо).
След преглед на получените регистрационни файлове се оказа, че твърде много достъпи до файлове се отнасят до грешни места и има много причини за това.
-Шрифтовесе отварят при поискване и Font Manager проследява използването на шрифта и ги затваря, когато използването падне до нула. получавате забавяне, докато шрифтът се зарежда от файловата система и компилира, това забавяне е средно 5-10ms. След това елементът изчезва от екрана... и Font Manager затваря неизползвания шрифт, подготвяйки ви за още 5-10ms забавяне, когато елементът, който изисква този шрифт, се появи отново.
-Материали- малки файлове от около 100 байта. Считаха се за твърде малки, за да бъдат кеширани... което е приемливо, ако са в буфер на файлова система или на SSD, но ако не, очаквайте 5-20ms латентност на файл.
-Cinematics- вид филм, съдържащ звуци, модели (с материали и текстури) и сценарий. Има много от тях в играта, вариращи от водопади до изстрели с железопътна пушка. Оказа се, че Kinematics кешира само техните текстури. И нищо друго. Това означава, че когато Kinematics за първи път играе вместо вас, тя започва да компилира модели,която все още не е съществувала. Преди да компилира, първо ги зарежда от файловата система... А кинематиката може да съдържа до 20 модела. И моделите се нуждаят от време за компилиране... здравей, 100+ ms латентност.
Кинематиката контролира неща като мигащи ефекти, кръвни отпечатъци и др. Познайте какво се случва първия път, когато попаднете в бъркотия, или срещнете ново извънземно, или оръдие на морски пехотинци.
-Графичен потребителски интерфейс (GUI)се използва за показване на HUD и е... странно. Целият lua код се зарежда при стартиране на клиента, но GUI кодът се зарежда при поискване. Така че първия път, когато станете джетпакер, или Exo, или Alien, GUI скриптът се компилира.
Не е критично, едно забавяне при мутиране в нова форма на извънземно не е особено досадно. Въпреки това, това взаимодейства много слабо с процеса на кеширане на неща в NS2. Вие кеширате активите, от които се нуждаете по време на компилиране, и когато lua кодът се зареди, на NS2 клиента се казва от кои активи има нужда. системата за кеширане не трябва да се използва вече по време на играта, в противен случай тя изобщо не се кешира. Следователно никакви активи, използвани изключително от GUI елементи, не се кешират ... и има 422 файла в директорията „ui/*“, които просто чакат да поставят следващия ви кадър.
-Още по-неясно нещо от GUI системата еGUI подсистемата, наречена GUIViews. Позволява ви да рисувате върху текстури и първоначално е реализиран чрез виртуалната машина Flash. Вграждането на Flash, за да ви каже колко амуниции остават в клип, е доста глупаво, така че Flash беше заменен с виртуална машина Lua (Lua VM). За съжаление, тя беше заменена от несъществуващата Lua VM,но индивидуална Lua VM. Една виртуална машина (VM) на дисплей. Така че редовният морски пехотинец имаше един отделен Lua VM за дисплея на щурмовата пушка и друг за дисплея на пистолета. О, да, още един за дисплея на строителните инструменти. Е, една за заварчика, ако имаше.
Не е толкова лошо, колкото си мислите, Lua VM са малки и евтини (по отношение на ресурси). Проблемът е, че дисплеите се създават и унищожават динамично. Ето, хвърлихте машината - Lua VM е унищожена. Повдигнахте машината и се създава нова Lua VM, зарежда своя код... от файловата система. И разбира се, lua кодът, използван за тези виртуални машини, няма достъп до кеширащата система, така че необходимите текстури и шрифтове не бяха кеширани. Сега знаете защо замръзвате за 100+ ms, когато вземете първата си пушка в днешната игра.
======= Във всеки случай повечето от тези неща (най-критичните) ще бъдат коригирани в Build 267, което ще добави плавност към играта. Останалите ще бъдат коригирани в Build 268.