Мне взбрело в голову проверить кол-во фпс в зависимости от разрешения на необновлённых движках ХЛ2, Эп1, Эп2. Результаты получились довольно интересными, я даже провёл кое-какие расчёты и смог сделать некоторые выводы. Все результаты выложены в виде трёх таблиц - в принципе, пошевелив мозгами, можно допереть, что к чему в моих таблицах, но я всё же рекомендую сперва почитать мои комментарии, и, по мере их прочтения, смотреть на данные в таблицах.
Часть 1. Замеры на родных картах.
1. Методика измерения. (Можно пропустить, если неинтересно и доверяете мне ^_^)
Ну, собсна, фпс измерялся на трёх основных движках - ХЛ2, Эп1 и Эп2 (пиратка Half-Life 2 Ultimate Edition 6), конфиг ПК в профиле. Для точного измерения фпс записывал демку на одной из игровых карт - как видно из таблиц, для ХЛ2 выбрал d1_canals_01 - для моего ПК она достаточно напрягающая из-за воды (при прыжке в воду фпс падает ниже 60), для Эп1 - ep1_citadel_03 - это карта с Ядром Цитадели, самое комповыносящее место в игре, для Эп2 - ep2_outland_01 - самая первая карта игры, на которой наблюдаем "портальный шторм" и обрушение вагончика вниз, что ещё больше распаляет мою несчастную видяшку. Настройки в ХЛ2 - максимальные, в Эп1 - сглаживание MSAA 8x вместо CSAA 16xQ (а вообще-то, один фиг; но моя система почему-то реагирует очень неадекватным снижением фпс на последний режим, ХЗ, кривые руки Нвидиа?), в Эп2 - отключены динамические тени и размытие при движении. Во всех играх, по понятным причинам также отключена вертикальная синхронизация. Тестирование проводил в режиме полного окна. Для достижения минимальных погрешностей, каждая игра запускалась с параметрами -console и +fps_max 1000. Для измерения фпс юзался встроенный в игру бенчмарк - команды bench_start и bench_end, которые для уменьшения погрешности и лучшей точности и скорости запуска, биндились на клавиши. После записи демки она один раз проигрывалась, выбиралось нужное разрешение, игра перезапускалась и запускалась демка с включением бенчмарка. После теста выбиралось следующее разрешение, игра перезапускалась и вновь включалась демка с бенчем - и так до самого последнего разрешения. Следовал от меньшего разрешения к большему.
В тщательности измерений можете мне довериться - когда разгонял видяху (а я этим занимался довольно тщательно, и даже не один раз (бывало сбрасывал на стд)), достаточно наловчился. Конечно, слишком точно эти результаты вряд ли можно воспринимать - какие-либо погрешности всегда будут, и один и тот же тест, выполненный, казалось бы, абсолютно одинаково, часто даёт разные результаты, тем не менее, вполне можно расчитывать на небольшую (максимум 1-2 фпса при порядке 100 к/с) погрешность.
2. Таблицы результатов.
resolution
frames per second
resolution
aspect
kilopixels
HL2*
EP1**
minEP1
EP2***
minEP2
640*480
4:3
307,2
86,62
102,67
52-55
59,46
30-39
720*576
5:4
414,72
90,67
103,87
38-40
49,41
25-31
800*600
4:3
480
90,75
96,88
37
44,71
23-26
1024*768
4:3
786,432
90,5
67,14
25-27
31,75
15-18
1152*864
4:3
995,328
90,38
54,03
21-22
26,25
12-15
1280*960
4:3
1228,8
90,16
44,68
17-18
21,8
11-10
1280*1024
5:4
1310,72
89,77
40,47
16-17
20,03
10-11
* d1_canals_01 ** ep1_citadel_03 *** ep2_outland_01
fps**
resolution 1
resolution 2
res*
EP1
EP2
640*480
720*576
1,35
1,2
720*576
800*600
1,16
1,105
800*600
1024*768
1,64
1,44
1,4
1024*768
1152*768
1,27
1,24
1,21
1152*768
1280*960
1,235
1,21
1,2
1280*960
1280*1024
1,07
1,1
1,09
* res=resolution2/resolution1 ** fps=fps1/fps2
resolution
720*576
800*600
1024*768
1152*864
1280*960
1280*1024
res*
1,35
1,56
2,56
3,24
4
4,27
fps** EP1
1,53
1,9
2,3
2,54
res/fps EP1
1,67
1,7
1,74
1,68
fps** EP2
1,2
1,33
1,87
2,265
2.8
2,97
res/fps EP2
1,125
1,17
1,37
1,43
1,43
1,44
* res=resolution/640*480 ** fps=fps(resolution)/fps(640*480)
3. Описание таблицы 1.
Для начала рассмотрим таблицу 1. Первые три колоночки - это различные характеристики, связанные с разрешением - собственно разрешение, соотношение сторон и кол-во пикселей на один кадр текущего разрешения (в тысячах штук, или килопикселях) - узнать кол-во пикселей в кадре до смешного легко - умножаем первую цифру разрешения на вторую. Следующие пять колоночек - собственно замеры фпс. В первой колонке - средний фпс, выданный бенчмарком для ХЛ2, далее - для Эп1. Под заголовком minEP1 имеется ввиду минимальное кол-во кадров в секунду при рассматривании ядра - одновременно это минимальный фпс на демке вообще - оно и понятно, ядро у нас прожорливое в этом смысле... Далее - средний фпс на демке Эп2, а под заголовком minEP2 указано два минимальных фпс - вторая цифра - это минимальные к/с, когда мы смотрим на портальный шторм, а первая цифра - это минимальные к/с, когда мы смотрим на обрушивающиеся вагончики. Обычно первая цифра - это и минимальный фпс на карте, но не всегда - на высоких разрешениях при осматривании местности ещё до вспышки портального шторма я засекал совершенно убийственные числа (8-9 на 1280*1024). Минимальный фпс Эп1 нам ещё пригодится, минимальный фпс Эп2 - чисто для информации/сравнения.
4. Анализ результатов для Half-Life 2.
а). ФПСу - независимость!
Первое, что бросается в глаза - удивительная схожесть результатов. При том, что размеры кадра отличаются порою в 4 раза, разница в фпс едва достигает 1-ого и находится на уровне погрешности. Вообще-то, этот результат и не должен удивлять былого халфера - в тестированиях видях (в основном старых, или встроенных, или ещё как-либо обделённых), авторы обзоров всё время удивляются практическому отсутствию изменений в счётчике кадров при изменении разрешения, часто называя такое поведение "странным". На самом деле - это обычное поведение ХЛ2. Но, должен сказать, данное замечание верно не всегда. Для старых видеокарт зависимость разрешение-фпс есть, например, для моей несчастной старушки Nvidia MX440 - может, разница не очень-то и большая, но всё же есть.
С чем связано безразличие старого билда ХЛ2 к разрешению, сказать не могу - то ли в движке есть некий определённый специальный "потолок", то ли он так хорошо масштабирует картинку - не могу сказать, тут моих знаний не хватает. В любом случае, Вэлвы склепали хорошее двигло - в меру (ныне) красивое и довольно производительное, жаль, что они своей последней эпик-обновой лишили его второго преимущества в пользу первого.
б). Эпик фэйл.
Во вторую очередь (после удивительной схожести результатов) вы наверняка обратите внимание на внезапный провал в строчке 640*480 - всего лишь 82 кадра/секунду! Как? Аффтар схалтурил?
Последнее исключено - результат перепроверен три раза, и все разы он подтвердился. Проседания фпс даже видны по счётчику фпс (он у меня всегда включен) - вспомните момент перед спрыгиванием в канал - мы идём к силовому полю и отстреливаем ГО-шников (оттуда после прыжка в канал поедет поезд) - в этом месте на 640*480 фпс падал ниже 60 (57-58), в других же разрешениях он стабильно держался на 62-64 - то есть, "цифры не врут" (c) House M.D. Мы имеем забавный "парадокс 640*480" - в этом разрешении ХЛ2 работает куда медленнее, чем в других. Интересно, верно ли это для старых машин?
в). Выводы.
Суммируя, делаем следующие заключения:
- в Half-Life 2 фпс практически не зависит от разрешения (на достаточно мощных ПК);
- Half-Life 2 не любит разрешение 640*480;
- максимальной производительности в Half-Life 2 можно добиться на разрешении 720*576 или 800*600 (опять-таки, по крайней мере, на достаточно мощных ПК).
Теперь нам предстоит проверить, верны ли эти выводы для Эп1 и Эп2.
5. Описание таблицы 2.
Для более тщательного анализа Эп1 я провёл кое-какие дополнительные расчёты - для ХЛ2 они бесполезны из-за практически одинакового фпс, а для Эп1 и Эп2 они помогут выявить кое-какие интересности. Результатами расчётов заполнены таблицы 2 и 3.
Суть таблицы 2 - сравнение двух соседних разрешений - т.е., мы сравниваем кол-во пикселей в кадре у двух разрешений и кол-во фпс в играх у этих же resolutions. Первые два столбика - сравниваемые разрешения. Второй столбик (res) - отношение кол-ва пикселей в одном кадре второго, большего разрешения к кол-ву пикселей первого, меньшего разрешения. Т.е., мы берём килопиксели для, скажем, 1024*768, и делим их на килопиксели для 800*600 (либо сразу 1024 умножаем на 768 и делим на 800 и на 600). Таким образом, мы узнаём насколько одно разрешение больше другого.
Следующие два столбика (fps), для Эп1 и Эп2 соответственно - это отношение большего фпс - для первого разрешения - к меньшему фпс - для второго разрешения. Т.е., в нашем примере мы берём из первой таблицы (т.о., вторая таблица основывается на данных из первой) средний фпс, полученный для 800*600 и делим его на средний фпс для 1024*768. Таким образом, мы узнаём, во сколько раз фпс для 800*600 (меньшего разрешения) больше, чем фпс для 1024*768 (большего разрешения). Чем меньше получатся эти цифры, тем, в принципе, лучше.
Т.к. для перых трёх разрешений Эп1 вышел небольшой разброс фпс, данные по ним я не привожу.
6. Описание таблицы 3.
Таблица 3 также основывается на данных таблицы 1. Она довольно похожа на таблицу 2, главное отличие - сравниваются уже не 2 соседних разрешения, а все разрешения поочерёдно сравниваются с самым маленьким - с 640*480 - и по размеру кадра (res) и по числу фпс (fps). После этого мы берём полученное число res и делим его на число fps - этими цифрами заполнены четвёртая и шестая строчки - причём чем больше эти цифры, тем лучше. Если бы зависимость числа фпс от разрешения была прямой (т.е., на сколько мы бы увеличили разрешение, на столько бы упала производительность), и мы бы построили по таким цифрам график, то у нас бы получилась бы прямая линия, задирающаяся вверх - но, по крайней мере, в большинстве игр на большинстве видеокарт эта зависимость непрямая, и график получается в виде более-менее плавной, относительно низкой кривой.
Т.к. для Эп1 720*576 и 800*600 слабо отличаются от 640*480 по числу фпс, данные по этим разрешениям я не привожу.
7. Анализ результатов для Episode One.
а). Ядро грузит!
Эп1 грузит мой ПК куда сильнее ХЛ2, и теперь мы отчётливо видим резкое падение фпс от меньшего разрешения к большему - разница примерно в три раза. Тем не менее, средние фпс для первых трёх разрешений довольно близки - неужто действительно существует некий "потолок фпс"? Забавно, что на примере Эп1 подтверждается правило, выведенное для ХЛ2 - даже этот билд Source'a не любит разрешение 640*480. Я даже перепроверил результат для этого разрешения - получилось 102,7 - очень близко. И я не просто так выписал в отдельную колонку минимальный фпс для ядра. Сравните и вдумайтесь - 52-55 фпс для 640*480 и жуткое падение ниже 40ка для 720*576! Шейдеры создают громадную нагрузку на систему (даже несмотря на то, что я сильно поднял частоту шейдерного домена). Но в остальных местах карты, где ядро не видно (правда, на демке я смотрел на ядро немало времени - и из панели управления (да ещё с зумом), где осталась Аликс, и пробегая снизу), фпс достаточно высок, чтобы компенсировать потерю драгоценных кадров на ядро и перегнать более низкое 640*480 - есть резон повторить эксперимент для какой-нибудь другой карты из Эп1, а может, и для всё той же d1_canals_01 - возможно, тогда получился бы и отличный результат для 800*600. Для 800*600 минимальный фпс у ядра почти совпадает с 720*576.
б). Выводы.
- Episode One также не любит 640*480;
- в Episode One больше всего ресурсов съедают продвинутые шейдеры и спецэффекты, именно они съедают ресурсы сильнее всего, и особенно зависимы от разрешения;
- в зависимости от типа карт наибольшей производительности в Episode One можно добиться либо на 800*600 на картах с минимумом шейдеров (предположительно), либо на 720*576 на картах с огромным кол-вом шейдеров (Ядро Цитадели).
8. Анализ результатов для Episode Two.
Переходим к тяжёлой артиллерии. Тут уже ни о каком "потолке фпс" речи не идёт, фпс стабильно падает при повышении разрешения. Наиболее полезной для нас является таблица 3, точнее - самая последняя её строчка. И что мы видим? Постепенное наращиваение отношения res/fps!
Ещё можно сделать вывод, что, по крайней мере, по сравнению с Эп1, у Эп2 с увеличением разрешения падение фпс происходит менее интенсивно...
Часть 2. d1_canals_01.
В этой части описаны результаты измерений из Эп1&Эп2 на карте d1_canals_01. Для этого я просто подключил GCFку с картами ХЛ2 к этим играм и записал на данной карте демку. На данной мапе при запуске на новых движках наблюдается баг - странные тормоза при появлении поезда, со слайдшоу 1 кадр на 2-3 секунды - но при воспроизведении демки этих тормозов и след простыл. Также учтите, что записывать демки пришлось по новой, так что ни в коем случае не сравнивайте эти результаты с результатами под ХЛ2 и друг с другом, хотя путь примерно тот же, но всё же есть много отличий, из-за чего средний фпс в Эп1 даже чуть выше, чем в ХЛ2.
2. Таблицы результатов.
resolution
frames per second
resolution
aspect
kilopixels
EP1
EP2
640*480
4:3
307,2
82,57
78,51
720*576
5:4
414,72
91,86
86,64
800*600
4:3
480
91,2
85,65
1024*768
4:3
786,432
85,45
81,63
1152*864
4:3
995,328
75,35
69,79
1280*960
4:3
1228,8
59,44
59,81
1280*1024
5:4
1310,72
57,96
56,02
resolution
1024*768
1152*864
1280*960
1280*1024
res*
1,64
2,07
2,56
2,73
fps** EP1
1,07
1,21
1,53
1,57
res/fps EP1
1,53
1,71
1,67
1,74
fps** EP2
1,05
1,23
1,43
1,53
res/fps EP2
1,56
1,68
1,79
1,78
* res=resolution/(800*600) ** fps=fps(resolution)/fps(800*600)
10. Анализ результатов.
Из этих результатов мы чётко видим, что разрешение 640*480 таки действительно нелюбимо Source'ом, причём явно всеми его версиями - даже для Эп2 на более высоких 720*576, 800*600, и (о ГО-сспади!) 1024*768, счётчик кадров в секунду выдаёт большие значения. Отсюда делаем вывод, что владельцам старых ПК стоит трижды подумать и дважды проверить, действительно ли стоит ставить именно такое разрешение.
Что касается каких-то конкретных разрешений, то 720*576 всё же даёт большие циферки, нежели соседнее 800*600.
Налицо и существование некоего "потолка фпс".
Возможно, любопытно будет взглянуть на графики, выражающие зависимость изменения фпс от изменения разрешения - данные взяты из таблицы 6, колонки 1 и 2 для Эп1 и 1 и 4 для Эп2. Как видите, в Эп2 график получился более гладким, т.е. фпс зависит от разрешения в меньшей степени, чем в Эп1.
Примечание: убедительная просьба НЕ редактировать данный документ без согласия его автора (xDDGx). Любые несогласованные правки будут убраны.
и это всё на разрешении 1366*768
я так понял что у тебя достаточно быстрый комп, но он тормоит(в еп1и 2). В разогнанном состоянии (а в дохе результаты по референсным частотам) меня фпс в Эп1 и Эп2 устраивает, не забывайте, что тестирования проводились на бэкграундах и в началах игр, где максимум спецэффектов и тормозов. А также имейте ввиду, что теперь, после великого обновления сорца 2010 года и ХЛ2, и Эп1, и Эп2 - на одной версии движка. Так что инфа, изложенная в этом дохе - устарела. немного меньше минимальных системных требований игры. Ты с ума сошёл, минимальные требования намного ниже твоих. Старые ХЛ2 и Эп1 спокойно запускались на моём старичке с MX440 64 МБ видеоОЗУ, 256 МБ ОЗУ и 1,8 ГГц AMD Sempron 2200+, хотя, конечно, фпс был низким, но стабильным - играть было можно даже в Эп1. И вообще, если у тебя тормозит - снижай настройки, ГРАФОН того не стоит, можно, напр, пожертвовать сглаживанием до 2X - картинка останется нормальной, а выигрыш в производительности значительный. и в хл2 при появлении поезда игра ужасно глюкала ~20 сек Неизвестно, с чем это связано, отмечу, что такое поведение наблюдается и у меня, но только в SMOD'e. хл2еп2 я не мог запустить сразу на макс графе, фпс падал до 9. надо было зайти в игру на макс игровой графе, затем свернуть и поставить настройки видюхи на макс. Юзай параметр -console для запуска игры, тогда карта-бэкграунд не станет загружаться, да и игра запустится быстрее. и это всё на разрешении 1366*768 Не самый распротсранённый видеорежим на момент выхода ХЛ2, есть подозрение, что Сорц - по крайней мере, старых версий - его не любил. Я вроде делал замеры для широкоформатных режимов (благо что у меня есть второй монитор 16801050), но эти результаты... Или не выкладывал, или не доделал... В общем, забил. В любом случае, эта инфа больше для интереса, чем для какого-то практического использования, и, нужно понимать - а я, на то время, об этом не подумал - что все причуды могут быть вызваны не столько движком, сколько видеокартой. К примеру, возможно, на самом деле, не Сорц не любит видеомоуд 640*480, а моя видяха... Для выяснения этого нужны более глобальные тестирования, с применением разных моделей и всё-такое.
Неизвестно, с чем это связано, отмечу, что такое поведение наблюдается и у меня, но только в SMOD'e И в целой плеяде старых пираток это есть. Хе, я даже на пиратках (а у меня по сути было только три — хл2 от псевдофаргуса, сорс 7, сборная хл2-эп1 пиратка, и ОБ, на котором не работали хл2 и эп1 (там просто вырезали мапы, сцены) — на первой и второй поезда тормозили) я даже при появлении бэка с коаста спешил поскорей ввести нужную мапу в консоль или сейв загрузить, пока поезд не начал ехать. инфа, изложенная в этом дохе - устарела Для модов на СДКБазе не так и устарела…
я даже при появлении бэка с коаста спешил поскорей ввести нужную мапу в консоль или сейв загрузить, пока поезд не начал ехать. о__О Мне повезло, таких поездатых глюков не наблюдал, даже в Смоде глючит только поезд в каналах, с другими проблем не наблюдалось...
я даже при появлении бэка с коаста спешил поскорей ввести нужную мапу в консоль или сейв загрузить, пока поезд не начал ехать. В моей ОБ-пиратке так же. И, насколько я помню, в лицухе до глобального обновления у меня тоже это было. о__О Мне повезло, таких поездатых глюков не наблюдал, даже в Смоде глючит только поезд в каналах, с другими проблем не наблюдалось... У меня он тормозит в каналах (несколько раз: когда обычный довоенный проезжает, в месте где ГО-шники бочку подожжённую скатывают и когда в воду прыгаешь) и Дороге 17 (в месте, где нужно его обгонять (ну или убегать от него, я обгонял обычно) и на бэкграунде с мостом). Причём в модах и после обновления эти проблемы не наблюдаются.
когда обычный довоенный проезжает, в месте где ГО-шники бочку подожжённую скатывают и когда в воду прыгаешь Но ведь там определённо едет бритвопоезд.
Но ведь там определённо едет бритвопоезд. Нет, я говорил о первом, по которому мы прыгаем на другую сторону.
(несколько раз: когда обычный довоенный проезжает, в месте где ГО-шники бочку подожжённую скатывают и когда в воду прыгаешь) Всё верно, три поезда - три зависания... В моём Смоде зависал только второй, поезд-лезвие. (в месте, где нужно его обгонять (ну или убегать от него, я обгонял обычно) xD Суров)) Причём в модах и после обновления эти проблемы не наблюдаются. В общем, проблема зависит от версии Сорса. Всё-таки, хорошо, что Вэлв не забывает про свои игры и обновляет их, исправляя допущенные ляпы.
xDDGx Всё под контролем)))) особенно после покупки компа =) если что, могу сообщить сист. требования при приобретении орандж бокса обновы мая 2011 г. , все глюки пропали- я писал про то, что поезда (на ст. ноудбиче) секундно глюкали, когда исчезали? 783001 И в целой плеяде старых пираток это есть-на оран. боксе(2006г. пир.)пока глюк поезда не встречал
я писал про то, что поезда (на ст. ноудбиче) секундно глюкали, когда исчезали? - забыл писал или нет8)
Я накаркал-все глюки поезда остались:*-(
xDDGx я так понял что у тебя достаточно быстрый комп, но он тормоит(в еп1и 2). про поезд - у меня ноутбич с параметрами Intel Pentium processor T4300 (2.1 GHz FSB) ATI Mobility Radeon HD 4570 Up to 2304 MB HyperMemory 15.6" 3D HD LSD 4 GB Memory 320 GB HDD Acer Nplify 802.11 b/g, вобщем, немного меньше минимальных системных требований игры. средний FPS 30 к/с, на максимальной графе , но это кокрас нормально... ...про поезд)) у меня стоял orange box 2006 года, и в хл2 при появлении поезда игра ужасно глюкала ~20 сек а также тогда, когда я смотрел на комбайновские стёкла(которые "плавают"). хл2еп2 я не мог запустить сразу на макс графе, фпс падал до 9. надо было зайти в игру на макс игровой графе, затем свернуть и поставить настройки видюхи на макс. при приобретении орандж бокса обновы мая 2011 г. , все глюки пропали