Тестирование скорости системы в играх на движке Quake

Stanislav Vasiliev
Kuzin Andrey

Предисловие

Движок Quake, созданный программистами iD Software достаточно давно, является даже на текущий момент достаточно ресурсоёмким, что в своё время при более слабых среднестатистических системах было ещё более актуально. Поэтому для замеров производительности каждой конкретной системы, в игру была включена возможность замера FPS (расшифровывается как Frames Per Second, или Кадров В Секунду) несколькими способами. В последствии, при создании движка Quake 2 эта система была сделана ещё более удобной и расширена некоторыми дополнительными возможностями. Так как в Quake впервые появилась такая вещь, как консоль, позволяющая вызывать практически любые комманды в любой момент времени, то и замеры производительности можно провести так же любым из двух возможных способов в любой момент нахождения в игре.

Способ первый - комманда timerefresh (пишется с одной r), кстати для того, чтобы вводить комманды в Quake, не надо набирать их до конца, к примеру для того, чтобы ввести эту команду, достаточно набоать timer и нажать TAB. Почему не time или не ti? Потому что тогда интеллектуальная система Quake подставит вместо refresh слово demo, и получится слово timedemo, которое, собственно, является второй коммандой измерения скорости.

Часть 1 - Синтаксисы комманд:

Комманды для Quake 1

• "timerefresh" - введя слово просто без всяких параметров, получаем простой тест скорости в FPS на одном месте.
• "timerefresh ]" - получено мной совершенно случайно, в следствие опечатки, при этом похоже изображение не выводится на экран, а вместо этого показывается сколько кадров максимум (на самом мощном акселераторе) мог бы выдать Ваш процессор, для сравнения в первом случае мой P2-450(464) показывал 155 FPS (Quake2, base1, сразу после начала), при втором - 195, что означает, что всё же пока узким местом явился акселератор. Хотя это мой вывод, и я нигде не видел никакой документации по этому вопросу (даже в полном списке комманд консоли Q)
• "timedemo ???" , где ??? - название демонстрации, к примеру если это стандартная демка Q, запускаемая при запуске, то она имеет название от demo1 до demo3 (всего 3 демки), но так же можно подключить любую другую демку, создав в каталоге ID1 папку с именем DEMOS, и скачав туда файл с расширением DEM. После чего написать в консоли timedemo name, и демка будет играться.

Комманды для Quake 2:

• "timerefresh" и "timerefresh ]"- совершенно идентично Quake 1.

• "timedemo 1" (1 включает режим timedemo а 0 - отключает) - синтаксис этой комманды был совершенно переработан. Кстати надо рассказать о принципе действия этой комманды. Насколько я понимаю, в стандартной игре есть некий лимит скорости происходящих событий, и все события каким либо образом привязаны к таймеру, то есть, если проще говорить, игра отдельно обрабатывает движение, и отдельно вывод визуализации этого движения. Так например пехотинец всегда делает один шаг в одну секунду, при этом например шаг состоит из 60 фаз (это я про анимацию персонажа), то есть поскольку в игре всё не как в жизни, то персонажи анимируются следующим образом - берётся нога (всё буду обьяснять немного грубо, и не всегда совсем так, как это реализовано программистами, и если кому интересно как это сделано на самом деле, он может пойти на любой сервер типа www.planetquake.com и там ознакомиться с огромными текстами по принципам работы движка Q), после чего ей прописываются крайние положения (например стоит и висит в воздухе), а затем примерно делается ещё 58 кадров анимации (как ходит ступня, как сгибается колено, ну и т.д и т.п), в результате мы видим плавное движение этой самой анимированной ноги. Теперь о том, как работает графическая часть - игра сама считает время, за которое нога должна быть опущена, но её совершенно не волнует рассчёт геометрии этой ноги и вопрос увидите ли вы эту ногу или не увидите вообще. Она просто считает где должна быть нога. А визуализацией занимается отдельный блок, который как раз здорово зависит от скорости вашего процессора, акселератора, памяти и др. составляющих системы (кроме звуковой карты, для неё тоже сделан отдельный блок), и когда у Вас слишком медленный компьютер, который например показывает только 5 кадров в секунду, то соответственно вы и увидите только 5 из 60 позиций этой ноги. А по русски мы это называем тормозами. То есть всё дёргается, попасть никуда нельзя, ну и т.д. А если у вас 120 кадров в секунду ? Тогда Вы увидите каждый кадр анимации ноги 2 раза. И вот как раз на этом и основано действие комманды TIMEDEMO, она включает синхронизацию этих двух блоков, и каждый из кадров анимации показывается на экране всего 1 раз. Соответственно если FPS меньше AFPS (анимационных фрэймов в секунду), то игра будет идти медленнее, если же их больше, то быстрее. И при всём этом будет производиться конкретные замерения количества кадров в секунду каждую секунду, а в конце будет выдано среднее значение. Не кажется ли Вам, что мы ушли далеко от синтаксиса ? А вот мне кажется... (Кстати ещё раз напоминаю, всё вышесказанное - жуткая интерполяция реальных технологий игры, и поэтому просьба тем, кто хорошо понимает в принципе работы движка Q не посылать мне мануалей по этому самому движку, они у меня есть, я просто пытаюсь кое что доходчиво обьяснить тем, кто таких мануалей не читал, но тем не менее хочет хоть примерно понять как оно работает). Так вот значит... Синтаксис таков: timedemo 1 или timedemo 0, при этом 1 включает режим отвязки от времени, и 0 - выключает. Соответственно если надо протестировать - то пишем 1, если хотим поиграть - 0. При этом режим timedemo работает и в игре. Главное отличие от Q1 в этой ситуации только то, что играется не одна демка, а вся игра переключается в ускоренный режим. Но ведь нам надо получить скорость в конкретной демонстрашке? А вот для этого и служит такая комманда как

• "demomap ???.!!!", где ??? - название основной части файла демонстрации (BASEQ2DEMOS для внешних демок), а !!! это расширение файла демонстрации. Для стандартных демонстраций оно DM2. Значит чтобы включить демонстрацию, надо набрать "demomap demo1.dm2" (опять напоминаю о том, что кавычки не нужны). После этого запускается демонстрация DEMO1 в ускоренном (замедленном) времени. Кстати для того, чтобы если у Вас _жутко_ медленный компьютер, Вам не приходилось смотреть на одну демку по пол года, сделана не полная рассинхронизация со временем. То есть если FPS большой, то всё будет идти слишком быстро, а вот если маленький, то всё будет идти как обычно, только опять таки с "тормозами". Но после просмотра демонстрации наступает ещё одна проблема: Quake 2 не только не выдаёт результатов, но ещё и запускает demo2 в том же темпе. Что делать? А делается так. Прописывается алиас на прокрутку демок с принудительным убиванием демосервера. Делается это следующим способом:

alias d1 "demomap demo1.dm2;nextserver d2"
alias d2 "killserver"
после чего (или перед чем) вводите timedemo 1, и просто убираете консоль, запускается демка, отыгрывается, заканчивается и выдаёт снизу FPS. Выглядит так :

Как видно из скрина, было проиграно 689 фрэймов анимации за 8 секунд и это получилось потому, что было около 86 fps в среднем.

Кстати по поводу комманды timerefresh в Quake 1 (и иногда в Quake 2) - на некоторых 3D карточках, почему то, при попытке сделать timedemo режим OpenGL переключается в Software, а значит больше 1-2 fps в результате через пару минут (пока крутится этот таймерефреш) Вы не получите. Я встречал такие проблемы раньше на Riva128, теперь вроде бы их исправили, а теперь встречаю на RivaTNT.

Quake 3 Arena Test 2

В вышедшей новой версии Quake 3 Arena код timedemo поправлен и работает как надо. Для тестирования необходимо вызвать консоль нажатием тильды (~ - прямо под Esc) и набрать "timedemo 1" после этого если нужно протестировать производительность в Q3Test1 то набрать "demo q3testdemo1", если нужно протестировать Q3Test2 то набрать "demo q3testdemo2". Игра прокрутит 1 раз демонстрацию и вывалится в меню. После этого надо вызвать консоль и записать результат FPS. Затем сменить разрешения и/или разрядность и снова запустить тест по новой.

Часть 2 - как оптимизировать скорость Quake для тестирования (и не только)

В Quake существует несколько способов добиться повышения производительности. Способ первый - убрать некоторые графические излишества. Второй - изменить некоторые параметры работы с OpenGL, третий - сделать звук попроще или изменить его параметры. Здесь я могу описать только два первых способа, так как никогда не оптимизировал в Quake звук, и не считал это нужным. Единственное что я могу сказать про звук, так это то, что если у Вас не Pentium II, всё же лучше поставить звук на Low Quality (быстрее будет, а разница всё же не настолько важна).

Итак способ первый. Графические излишества. Что подходит под эту категорию? Ну например 16-ти битные текстуры. Чем они так плохи? Сейчас я это проиллюстрирую. Берём зайца...

8 бит текстура (320x240). Занимает 99Кб памяти

16 бит текстура (320x240). Занимает 297Кб памяти

Как видно из иллюстраций, практически, при нормальном дитеринге (Dithering, дисеринг, пока не определился с правильностью написания этого слова по-русски) качество 8 и 16 бит текстур можно свести к практически идентичному, но вот обьём ОЗУ, необходимый для хранения таких текстур может иметь довольно большую разницу. Сравните например 100 текстур по 100Кб и 100 текстур пл 300Кб. Результат - 10 и 30 мегабайт соответственно. А ведь ещё нужно держать в памяти уровень, звуки, события, настройки, и кучу всего другого. Так что сами понимаете, что в такой ситуации довольно сильно нагружается память. А в Quake 2 вы сможете на глаз определить качество текстур только на улице, так как небо становится гораздо более похабным. Ну да кстати что то не верится, что нельзя было отоптимизировать небо под 256 цветов. Либо они не знали о дитеринге ;-))) в чём я сомневаюсь, либо это просто какой то хитрый рекламный трюк. Кстати смена глубины цвета текстур на карточках Voodoo Graphics как сейчас помню приносила в Quake процентов так 20 производительности. Количество цветов меняется под кнопкой Video Options - 8 bit textures : yes

Кстати, что означают надписи на этом экране: Driver - выбор метода взаимодействия с видео адаптером, ести такие варианты - через стандартный OpenGL (такой же как для 3D заставок Windows и 3D MAX к примеру), 3Dfx OpenGL - только для карт на основе Voodoo Graphics (пример - Diamond Monster 3D, Canopus Pure 3D), Voodoo Rush и Voodoo 2 (Diamond Monster 3D II). Для карт на основе Voodoo Banshee и Voodoo 3 нужен специальный патч (вернее новая версия этого драйвера). Далее - Video mode, и выбор от 320x200 до 1600x1200. Вот примерная таблица разрешений, с которыми разным чипам рекомендовано работать (ИМХО).

Software	320x200 (максимум - 400x300, что бы у вас не стояло, хоть P2-XEON)
Voodoo Graphics (Voodoo1) & Voodoo Rush	512x384, 8bit textures
Voodoo 2 - 8Mb	640x480, 800x600 (медленновато всё же), 8bit textures
Voodoo 2 - 12Mb	640x480 и 800x600, можно и 16bit textures
Voodoo Banshee	800x600, 16bit (можно восемь бит, если мало памяти)
Voodoo 3	800x600,1024x768,1280x1024, 1600x1200 сколько угодно бит, хоть 8 хоть 16, всё равно буфер текстур достаточно большой.
Riva128	512x384, 16bit (за счёт AGP образного текстурирования, но как всегда всё зависит от количества ОЗУ)
RivaTnT (16Мб)	640x480-1024x768, 16bit без проблем, около 12Мб буфера текстур. Вполне хватает. Да ещё и AGP 2x... Лучше не ставить 32бит цвет, разницы почти никакой (см. картинки снизу), зато производительность падает.
RivaTnT 2	Что угодно, вплоть до 1600x1200, даже при 16 бит текстур и 32бит экрана, играть всё равно можно. Мне показалось, что наиболее рабочее разрешение у неё - 1024, всё очень быстро. Конечно я имею в виду на P3-500.
Остальные 2D/3D карточки я сам в руках не держал, поэтому ничего конкретного сказать не могу.

Затем там идут Screen size, brightness и full screen (yes o), это соответственно размер экрана в игре (не разрешение а размер!), яркость изображения и параметр, регулирующий запускать ли игру на полный экран или же в окошке на рабочем столе.

Texture quality - по видимому уменьшает размер текстур. За счёт этого можно было на стареньких 3D карточках получить парочку лишних FPS.

Sync every frame - то же самое, что в настройке драйверов параметр Wait for VSync, при этом игра не показывает больше кадров в секунду, чем может показать ваш монитор. Это может сильно её замедлить. Кстати по поводу человеческого зрения читайте в конце.

Цветность:

16 bit экрана при 8 битах текстур. 640x480

16 бит экрана, 16 бит текстур

32 бита экрана при 16 битах текстур. Ну как, нашли разницу?!
Теперь вот ещё немного...

Ну как разница? Сверху - 16 бит экран, снизу - 32 бит.

Конечно JPG это не самый хороший формат для передачи цветности, но всё же... Стоит ли это потери производительности от 5(TnT2) до 25% (TnT1)?

По-моему нет...

Одно необходимое замечание:
Текстуры в Q очень хорошо оптимизированы, что является несомненной заслугой разработчиков, демонстрирующее крайнюю степень заботы и уважения к потребителям. К сожалению, не все могут похвастаться таким качеством и ответственностью и на других играх возможна огромная разница при воспроизведении 16 и 32 бит цветности.
Отпимизация текстур это высший пилотаж работы с графикой. Требующий кропотливости и времени. Поголовный перевод видеокарт на режим 32-битного цвета снимает головную боль прежде всего разработчикам, и нужен только им. Обычный человек с обычными глазами эту разницу даже не заметит. Но производителям необходимо рапортовать о новых достигнутых высотах, а игровым компаниям необходимо сократить время разработки игр. Отсюда растут эти 32-х битные ноги. Но возмущаться безполезно. Все равно нас застявят покупать P3 и TNT 2.

Что ещё... Ну можно отключить оружие. То есть просто убрать его с экрана. Делается через MULTIPLAYERPlayer Setuphandednesscenter (как на картинке внизу)

Это даст ещё небольшой прирост производительности, да к тому же оружие не будет загораживать пол экрана.

Пожалуй на этом список излишеств можно закончить... Теперь о режимах OpenGL:

Есть в Q такие комманды как

gl_ztrick
gl_swapinterval
gl_ext_swapinterval
gl_texturemode
gl_rounddown

и ещё некоторые другие, огромный текст можно поискать на ftp://ftp.cdrom.com/pub/planetquake там среди текстов лежат FAQ по коммандам Quake и Quake 2. Если лень рыскать по ftp, то можно сходить на www.planetquake,com, там тоже много интересного.

Часть 3 - Описание команд

gl_ztrick 1 или 0

меняет режим работы с Z буффером, при выставлении в 1 даёт производительность, но может на некоторых картах давать небольшие артифакты.

gl_swapinterval и gl_ext_swapinterval

Устанавливают задержки при работе с буфером. Задержки можно убрать, выставив значение в 0. На картах Voodoo 2 насколько я помню, давали большой прирост производительности.

gl_texturemode

Устанавливает режим фильтрации текстур. Бывает вообще без фильтрации (gl_mipmap), Point Sampled (gl_linear), билиненый (linear_mipmap_nearest) и трилинейный (linear_mipmap_linear). Для установки билинейной фильтрации (достаточно быстрая и неплохо выглядит) надо написать gl_texturemode GL_LINEAR_MIPMAP_NEAREST. Кстати о видах фильтрации - к примеру на чипах Voodoo 2, Voodoo 3 она бесплатная (то есть не отнимает никаких дополнительных ресурсов), на чипах TnT2 - тоже, а вот на Riva TnT можно либо накладывать две текстуры за такт, либо делать трилинейную фильтрацию. При этом сама фильтрация выглядит не слишком хорошо, чтобы ею пользоваться (слишком уж размываются текстуры вдалеке).

gl_rounddown (1 или 0 в Quake)

Случается так, что текстуры бывают нестандартных размеров. Например не 256x256, а 260x260, и вот эта опция отвечает за то, чтобы изменять их размер в случае необходимости до стандартного. (Например увеличивать текстуру с 260x260 до 512x512 точек, что соответственно меняет размер текстуры и количество памяти, для неё выделенной. Соответственно на некотрых карточках, на которых недостаточно текстурной памяти и нет AGP образного текстурирования это может существенно замедлять работу.

Часть последняя, про глаза.

Как известно, кино у нас, это 24 кадра в секунду, а игра может показывать на современном акселераторе более сотни этих чебурашек. Но стоит об этом сказать, то получаешь в итоге ответ, что человек не видит более 24 кадров в секунду. В связи с этим хотелось бы пояснить, что в оригинале заложена следующая мысль - человек воспринимает более 24 кадров в секунду, как непрерывное движение... А если кадров больше, то это движение он воспринимает как более плавное. Для примера поставьте на своём мониторе развёртку в 60 герц и посмотрите на него краем глаза. Вы должны УВИДЕТЬ мерцание, а это значит что вы видите эти 60 кадров в секунду. А вот если вы поставите 100Hz, тогда мерцание скорее всего будет уже не различимо. Вывод - если игра показывает около 100 кадров в секунду, то это самое оно. Кроме того человек достаточно с трудом различает разницу между 65536 и 4294967296 цветов (16 и 32бит палитра), даже с учётом того, что у TnT Z-Buffer не 32 а 24bit, всё равно 16777216 цветов, это довольно много. А за счёт того, что карте приходится прогонять через память гораздо более огромные массивы данных, скорость работы снижается (иногда не сильно, иногда сильно, а иногда просто катастрофически), а вот это, в отличие от цветности, человек видит отлично.

И наконец о нестандартных типах мониторов - например LCD панелях. У меня недавно была на тестировании такая панель с диагональю 15" от Bliss (модель 1500), у неё вообще возможность вывода только в 1024 и 262 тысячи цветов. Вот как раз для такой панели в идеале подходят последние карты на чипах TnT2 и Voodoo3, так как имеют отличную производительность в этом разрешении, и даже некоторые из них работают только в 16 бит цвете. Единственное, что на карте не должно быть при этом никаких наворотов, иначе у монитора будет нестандартная PHASE, и толк от покупки ценой в 1000 нерублей за 15" будет минимальным.

И ещё немного о мышке. Известно, что частота обновления мышки в приложениях от Microsoft - 40Hz. Что это значит? Это значит что в случае, когда у Вас 100fps в Quake, во время поворотов Вы будете получать досадные рывки, которые интерпретируются кстати некоторыми людьми как тормоза. Это не так. Для решения этой проблемы есть 2 выхода. Первый, купить мышку Genius Net Mouse (Pro) или другой их манипулятор со скроллом. Что обойдётся Вам +-примерно в 5-15$. Даже в COM исполнении драйвера этих мышек меняют опрашиваемость порта, достигая гладкости в играх. Плюс свежайшие драйвера с сервера Genius поддерживают стандарт DirectInput от Microsoft, что тоже довольно хорошо в играх. Способ второй подходит тем, у кого мышка стоит на PS/2 порту. Этим людям ничего не надо делать, только скачать программу PS2RATE (13 кб). После запуска программы выйдет окно, в котором можно будет выбрать частоту обновления порта PS/2. Не ставьте частоту больше, чем ваша частота обновления монитора, иначе не будет в этом смысла, даже если мышка будет обновляться 200 раз, вы всё равно этого не увидите. А зачем нужна такая частота обновления, я сейчас попытаюсь обьяснить. К примеру у Вас стоит в Quake разрешение 640x480 точек. Также известно, что в Quake видно на экране за один раз не более 90 градусов, а значит эти 640x480 для 360 градусов нужно умножить на 4, соответственно только горизонтальные точки, про вертикальные пока можно забыть. В результате мы имеем 2560 точек. И когда мы делаем резкий разворот мышкой на 180 градусов, то перед нами пролетает за секунду около 1280 точек. А обновление мышки например 40Hz. Соответственно получаем что поворот осуществлён с интервалом в 32 точки. И если нам надо было при этом попасть во время поворота в другого игрока по сети, который находился далеко, и по ширине был не более к примеру 20 точек, то есть большая вероятность что Вы в него не попадёте. Просто проедете мимо. А при обновлении мышки в 100Hz, уже интервал по 13 точек, и попасть будет легче.