Doom 3 не меняется разрешение

Главная / Doom 3 не меняется разрешение

Doom 3 не меняется разрешение

Вот вам народ некоторые способы оптимизации DOOM3.
Очень полезная инфа.

Для начала — рекомендую проделать парочку незамысловатых операций, которые заметно увеличат производительность:

В x:xDoom 3base есть несколько файлов с расширением .pk4. Каждый из этих файлов — всего-навсего архив, который содержит запакованные текстуры и прочие данные, именно их приходится бедняге-Думу каждый раз распаковывать, загружая при этом процессор, но мы ведь здесь для того чтобы помогать, не так ли? Разархивируйте WinRar’ом все архивы в base/, в случае повтора файлов — заменяйте. После этого удаляем файлы с расширением .pk4 и наслаждаемся приростом производительности. В файле DoomConfig.cfg есть такая строчка: seta image_cacheMegs и какой-нибудь параметр, например — 32. Если в вашем компьютере установлено 512мб памяти и больше — то рекомендуется сменить значение на что-нибудь более значительное, например — 90. Производительность опять возрастает.

Изначально игра очень и очень темная, но это не беда, нам помогут такие команды, как:

seta r_brightness «2»
seta r_gamma «2»

Согласно задумке — все должно стать чуточку светлее. Всего настроек графики очень много, если вас это заинтересовало — то обращаемся к соответствующему руководству.

Полезные консольные команды.

Консоль вызывается комбинацией клавиш: CRTL+ALT+

, но чтобы поставить консоль на привычную всем тильду — следует набрать вот это: com_allowConsole 1

Основные консольные команды:
Вот и команды консоли (

r_mode: меняет разрешение
r_mode 1 (400×300)
r_mode 2 (512×384)
r_mode 3 (640×480)
r_mode 4 (800×600)
r_mode 5 (1024×768)
r_mode 6 (1152×864)
r_mode 7 (1280×1024)
r_mode 8 (1600×1200)

r_shadows — включает и выключает динамические тени.
g_showPlayerShadow — включает и выключает отображение тени игрока.
g_showGun — включает и выключает отображение оружия
com_drawhud — включает и выключает отображение HUD
r_depthbits — глубина цветности текстур (16, 24, 32)
r_colorbits — количество отображаемых цветов 16 бит или 32 бит
r_gamma — изменяет значение яркости, чем больше тем ярче
image_anisotropy — меняет уровень анизотропной фильтрации, чем меньше тем быстрее. Рекомендуется выставить 1 или 2.
image_usePrecompressedTextures — использовать сжатые текстуры, рекомендуется выставить 1, будет быстрее грузиться
com_drawfps — включает и выключает отображение количества FPS (кадров в секунду)
r_useStandartGL — включает и выключает бамп-маппинг (металлический блеск у стен, слюна у монстров и т. д.)
s_noupdates — при 1 отключает звук, что приведет к значительному приросту FPS, срабатывает только после s_restart.
pm_thirdperson — при значении 1 переключает на вид от третьего лица. Hе рекомендуется на слабых машинах.
image_filter — рекомендую поставить GL_LINEAR_MIPMAP_NEAREST, увеличит скорость при незначительной потери качества картинки.
всё работает только после vid_restart
Для изменения управления (да и всего вышеперечисленного) необходимо редактировать конфиг /base/DoomConfig.cfg.
Чтобы запустить карты, которые есть в Doom3 Alfa, нужно ввести в консоли вот какие команды:

map e3/intro — заставка, чтобы поехала дальше крутящегося логотипа нажмите Ctrl или левую клавишу мыши

map e3/e3_1 — первая карта
map e3/e3_2 — вторая карта, код на двери — 924
map e3/e3_3 — третья карта
Это те карты, что крутились на E3.

Hу, и напоследок, как респавнить монстров:

spawn monster_demon_hellknight — «Рыцарь ада»
spawn monster_demon_imp — «Имп»
spawn monster_demon_pinky — «Розовенький»
spawn monster_zombie_security & security2
spawn monster_zombie_commando & commando_cgun — «Командир зомби»
spawn monster_zombie_maint — «Обычный зомби»
spawn monster_zombie_fat & fat2 & fat_ragdoll — «Жирный зомби», последний тот, что катится с лестницы на 3 уровне.

rugame.narod.ru

MAX SETTINGS! МАКСИМАЛЬНОЕ КАЧЕСТВО ГРАФИКИ!

autoexec.cfg

Если у вас проблемы с применением настроек графики DOOM 3, и при этом качество текстур не меняется, и остается одинаково низким — что на минимальных настройках, что на ультра настройках, то вам сюда.

Для включения максимального качества графики в игре DOOM 3 вам нужно зайти в папку «base» — в корне игры и создать там файл «autoexec.cfg» (без кавычек, если не знаете как создать — то создаете «текстовый документ.txt», переименовываете его в autoexec.txt и потом меняете расширение txt на cfg. В результате получается файл autoexec.cfg.)

После того как вы создали данный файл — открываете его блокнотом, и копируете туда данные строчки:

seta r_customWidth «3840»
seta r_customHeight «2160»
seta r_mode «-1»
seta r_aspectRatio «1»
seta r_useLightScissor «0»
seta r_skipNewAmbient «0»
seta r_forceLoadImages «0»
seta r_ignoredownsize «1»
seta r_sb_ScreenSpaceShadow «0»
seta com_videoRam «512»
seta com_machineSpec «3»
seta image_filter «GL_LINEAR_MIPMAP_LINEAR»
seta image_roundDown «0»
seta image_useCompression «0»
seta image_useNormalCompression «0»
seta image_usePrecompressedTextures «0»
seta image_downSize «0»
seta image_downSizeBump «0»
seta image_downSizeSpecular «0»
seta image_useCache «0»
seta image_ignoreHighQuality «0»
seta g_showPlayerShadow «0»
seta g_bloodEffects «1»
seta g_decals «1»
seta g_showBrass «1»
seta g_projectileLights «1»
seta g_doubleVision «1»
seta g_muzzleFlash «1»
seta g_showHud «1»
seta g_showProjectilePct «0»

Внимание: параметры seta r_customWidth «3840» — seta r_customHeight «2160» меняете на свое усмотрение — это ваше разрешение экрана. Если у вас монитор 1920×1080 — но при этом ваша видеокарта достаточно мощная и поддерживает режим разрешения DSR — то можете оставить так как в данном конфиге. Изображение будет обрабатываться в 4К разрешении и масштабироваться до FullHD, в результате картинка будет четче.

После проведенных манипуляций сохраняете файл и в свойствах ставите галочку — только чтение.

Сглаживание потом вы можете поставить в настройках самой игры.

If you have problems with graphics settings DOOM 3, and the quality of the texture does not change, and remains equally low — that the minimum settings that on ultra settings, then you here.

To enable maximum quality graphics in the game DOOM 3 you need to go to the folder «base» — the root of the game and create a file there «autoexec.cfg» (without the quotation marks, unless you know how to create — that create a «text Document.txt» rename autoexec.txt it in and then I was on the txt extension cfg. The result is a file autoexec.cfg.)

Once you have created the file — you open it with Notepad, and copy the data to the lines:

seta r_customWidth «3840»
seta r_customHeight «2160»
seta r_mode «-1»
seta r_aspectRatio «1»
seta r_useLightScissor «0»
seta r_skipNewAmbient «0»
seta r_forceLoadImages «0»
seta r_ignoredownsize «1»
seta r_sb_ScreenSpaceShadow «0»
seta com_videoRam «512»
seta com_machineSpec «3»
seta image_filter «GL_LINEAR_MIPMAP_LINEAR»
seta image_roundDown «0»
seta image_useCompression «0»
seta image_useNormalCompression «0»
seta image_usePrecompressedTextures «0»
seta image_downSize «0»
seta image_downSizeBump «0»
seta image_downSizeSpecular «0»
seta image_useCache «0»
seta image_ignoreHighQuality «0»
seta g_showPlayerShadow «0»
seta g_bloodEffects «1»
seta g_decals «1»
seta g_showBrass «1»
seta g_projectileLights «1»
seta g_doubleVision «1»
seta g_muzzleFlash «1»
seta g_showHud «1»
seta g_showProjectilePct «0»

Note: Options seta r_customWidth «3840» — seta r_customHeight «2160» change at its own discretion — it’s your screen resolution. If you monitor 1920×1080 — but your graphics card is powerful enough, and supports resolution DSR — you can leave it in this config. The image will be processed in 4K resolution and scale up to FullHD, as a result of the picture will be clearer.

Following the manipulation and save the file in the properties put a check — read only.

Smoothing then you can put in the settings of the game.

steamdb.ru

Особенности тестирования и настройки Doom3

. а также полное описание всех команд и переменных внутри игры. Долгожданный Doom3 всё откладывали и откладывали. И вот наконец, в августе 2004 года этот вожделенный продукт появился на рынке. И что же мы имеем?

Вот и дождались мы Doom3. В сети мгновенно появилось огромное количество обзоров игры в основном говорящих о супер красивой графике и мега мощном геймплее. Тёмные коридоры, хищные монстры и ужасные вопли наполнили уже дома многих любителей погеймится в компьютерные игры. Более того, многие люди специально апгрейдили компьютер под эту игру, решая, что вот эта видеокарта однозначно потянет Doom3. Этот процесс начался уже довольно давно, поэтому многие наивные души, купившие себе видеокарту пару лет тому назад для Doom3 сейчас думают, что были неправы. Поводом для многих споров, касающихся требований к железу новоявленного героя, была альфа версия, украденная с E3. В тот момент было много споров. Те, у кого игра безбожно тормозила, в один голос кричали – “Кармак умный, он сделает так, что Doom3 в максимальном качестве будет работать со скоростью скорострельного пулемёта даже на GeForce 4 MX-Series, а в альфа версии нет оптимизаций под современные процессоры и специфику графических карт”. Те, кто обладал большим опытом – возражали, и говорили, что финальная версия будет медленнее, чем вызывали у любителей GeForce 4 MX-Series припадки ненависти с выделением энергии на все окружающие предметы. Время шло. Долгожданный DooM всё откладывали и откладывали. И вот наконец, в августе 2004 года этот вожделенный продукт появился на рынке. И что же мы имеем?

А имеем мы три поколения сменившегося железа со времён кражи Альфа версии. Да-да, когда появилась Альфа версия, мы все читали статьи о GeForce4 Ti4600, а ATI вообще в серьёз не воспринимали. Топовый процессор на тот момент был Intel Pentium 4 2.8ГГц без HyperThreading, а 90% пользователей мечтало поиграть в DooM на 1400 Athlon. И всё это топовое железо того времени, финальная версия Doom считает хламом. Большинство видеокарт продающихся даже на настоящий момент на рынке в средних и нижних ценовых диапазонах, то есть 50-200 долларов, тоже не потянут Doom в концепции “Играйте в игры, как их задумывал разработчик”. Но не в одной видеокарте дело. Минимальные требования игры звучат так:

“Pentium 4 chip or AMD Athlon 1500, 384 megabytes of memory, two gigabytes of hard drive space, an nVidia GeForce 3 graphics card or better or an ATI Technologies 8500 or better. If you’re still keeping a GeForce 2MX/4MX and an older Pentium III in your PC, now’s the time for an upgrade and here are a few tips.”

Начнём разрушать иллюзии с памяти. Установленное опытным путём минимальное количество памяти, на котором можно “играть” в Doom на конфигурации HIGH это 768Мбайт. На 512Мбайт вы будете играть примерно 2\3 времени, одну треть игрового процесса компьютер будет играть сам с собой, а точнее со своим жёстким диском, измеряя возможности по выращиванию SWAP-файла до заоблачных величин. Про 384Мбайт даже думать страшно, потому что там играть будет можно только в перерывах между постоянной работой жёсткого диска. Панацеей от подобной болезни послужит переключение графики в режим Medium, но как упоминалось в предыдущем абзаце, это уже будет компромисс.

Далее, Doom умеет тормозить и сам по себе. В некоторые моменты игры, начинается дозагрузка текстур, и машина замирает на 1-5 секунды, даже если оперативной памяти в компьютере 1Гбайт. Особый аншлаг бывает в ситуациях, когда вы открываете дверь в большое пространство, где естественно прячется куча монстров. Дверь открывается и вы видите всё еще закрытую дверь, хотя она должна бы открыться. Вы дёргаете мышью – никаких действий. И вдруг, вы стоите к двери спиной, а вашу спину уже глодает пара чертей. Пока вы смотрели на якобы закрытую дверь, машина загружала текстуры пространства за дверью, действия вашей мышки были записаны, а как только загрузка текстур закончилась, воспроизведены.

Про процессоры и видеокарты для комфортной игры мы поговорим отдельно. А сейчас мы рассмотрим методику тестирования, которая поможет нам в дальнейшем разобраться с особенностями настройки и игры в Doom3.

Методика тестирования

Многие производители игр на настоящий момент не очень то жаждут, чтобы их продукты использовали как бенчмарки. Это связанно с желанием остаться в стороне от жёсткой политической игры между производителями компьютерного железа. ID-Software никогда не относилась к этим компаниям и вряд ли когда-нибудь к ним присоединится, так как её продукты всегда использовались как основные бенчмарки для оценки производительности современного железа. Doom3 не исключение. Если не считать официального модуля Doom3 Benchmark для использования в компонентных бенчмарках, сама по себе игра так же является высококачественным измерителем производительности, способной работать как в пользовательском режиме, так и в режиме командной строки.

Консоль для ввода команд в Doom3 вызывается нажатием CTRL+ALT+”

”. Если вы планируете пользоваться консолью постоянно, то мы рекомендуем создать в каталоге /base файл autoexec.cfg и внести в него команду:

seta com_allowconsole «1»

После этого, консоль будет открываться по нажатию одной кнопки “

”. Что же касается созданного файла autoexec.cfg, то все записанные в него команды будут исполняться в момент запуска Doom3.

Финальная версия Doom3 поддерживает три вида демо файлов и мы рассмотрим их по порядку. Все демо файлы автоматически располагаются в каталоге “/doom3/base/demos/”, а скриншоты в каталоге “/doom3/base/screenshots/”.

Первый вид — это классические демо-файлы, в которых записаны все действия игрока после введения в консоли:

где имя файла, который будет сохранён в обозначенном выше каталоге с расширением .demo. Для остановки записи демо-файла используется команда:

Для воспроизведения записанного ролика используется команда:

Расширение можно не писать, оно подставляется автоматически. При этом записанный ролик воспроизводится со всеми паузами и правильным временным распределением, то есть, в точности повторяет все действия игрока, как будто он сам сидит за клавиатурой.

В отличие от Альфа версии, финальный Doom3 не требует никаких дополнительных настроек для нормальной работы команды timedemo и имеет нормально записанные, встроенные демо-ролики. Для измерения производительности используется команда:

Данная команда воспроизводит записанный ролик с максимально возможной скоростью для тестируемого компьютера, а после окончания воспроизведения выводит результат в окошке. Подобный метод тестирования очень удобен, при желании пользователя получить отдельный результат. Но если хочется провести комплексный тест, то гораздо удобнее использовать команду.

Вышеуказанная команда выходит из игры в операционную систему после воспроизведения демо-ролика. При этом, результат тестирования можно посмотреть в файле журнала консоли, который нужно предварительно активировать с помощью команд:

Где имя файла журнала. Данный файл будет сохранён в каталоге “/doom3/base/” Результат же будет находиться в конце файла. Подобная система очень удобна при построении бенчмарка на базе пакетных файлов операционной системы.

В Doom3 встроен уже записанный ролик demo1.demo, с помощью которого можно проводить тестирование. Скорее всего, данный ролик станет стандартом де-факто для тестирования производительности в Doom3, так как его не требуется скачивать с сайтов тестовых лабораторий и при этом он обладает всеми необходимыми для тестового ролика качествами.

Создать файл в “/doom3/base/– demoauto.cfg и вставить в него в следующие строки:

logfile 1
Set D1 «timedemoquit demo1»
vstr D1

Затем запустить Doom3 из командной строки со следующими параметрами:

start /wait doom3.exe +exec demoauto.cfg

Результат будет выведен в файл “/doom3/base/qconsole.txt”. Параметры Doom3 можно менять с помощью файла “/doom3/base/DoomConfig.cfg”.

Второй вид демо — статический кадр. При записи такого ролика записывается положение всех персонажей и точки зрения камеры на момент введения команды:

При этом записывается один кадр, в котором всё происходящее на экране, включая постоянно движущиеся элементы (машины, роботы, световые эффекты) — заморожено. Имена файлов подобных демо-роликов всегда начинаются на “shot_” а имя, указанное в переменной прибавится к “shot_”. Если имя не введено, то к “shot_” будет прибавлен порядковый трёхзначный номер. Данная команда нужна для организации создания тестовых скриншотов с игры.

Воспроизведение статических демо файлов обеспечивается с помощью стандартной команды:

После запуска ролика статичный кадр висит до нажатия кнопки “ESC” или следующей команды из консоли. Скриншот с экрана, при этом, можно сделать с помощью кнопки “PrinttScreen” или с помощью консольной команды:

Скриншот после этой команды будет сохранён в каталоге “/doom3/base/screenshots/” в стандарте TGA . Внутри игры так же записаны две статические сцены shot_demo001 и shot_demo002, которые мы рекомендуем использовать для сравнений качества графики.

Пример для одиночного результата:

Пример для автоматизированной системы:

Создать файл в “/doom3/base/– scr.cfg и вставить в него в следующие строки:

playdemo shot_demo001
wait 200
screenshot
playdemo shot_demo002
wait 200
screenshot
quit

start /wait doom3.exe +exec scr.cfg

Результат будет выведен в каталог “/doom3/base/screenshots/shotXXXXX.tga”. Параметры Doom3 можно менять с помощью файла “/doom3/base/DoomConfig.cfg”.

Третий вид – демо по лог файлу из командной строки. Данная функция позволяет записывать демо-ролик без предварительного введения команды записи ролика, то есть пост-фактум. К примеру, вы особо удачно прошли уровень, а ролик на запись не поставили. После введения команды:

Ваши действия будут полностью восстановлены по консольному файлу-журналу и сохранены с момента загрузки карты до момента ввода команды. Всё бы ничего, но есть в этой команде и свои минусы. Так как запись идёт с записей в “командной строке”, а команда wait при игре не запоминается из-за работы в реальном времени, то все действия не имеют между собой промежутков и ролик воспроизводится почти со скоростью TimeDemo. Плюс, если искусственный интеллект переиграет действия монстров, к примеру, из-за изменения быстродействия компьютера, то сценарий сломается, и вы будете убиты в ролике, тогда как в реальности блестяще прошли это место. Повторное воспроизведение ролика всё может поставить на свои места. В связи с этим мы посчитали данную функцию недоработанной. Так же существует вариант, что мы просто не придумали ей правильного назначения.

Данные демо файлы сохраняются в стандартной директории с именем “ .cmd” Воспроизвести записанный ролик можно с помощью команды:

Так же присутствует команда:

С нашей точки зрения результат её работы некорректен.

Ну раз мы разобрались с тем, как тестировать в Doom3, значит можно переходить к рассмотрению особенностей игры. Для начала мы рассмотрим, чем же отличаются предустановленные аппаратные конфигурации внутри Doom3?

Профилей качества графики в игре четыре и все они отличаются друг от друга не так уж и сильно. Мы проанализировали разницу в профилях и составили следующую таблицу:

www.ferra.ru

Разрешение экрана.

This topic contains 8 replies, has 3 voices, and was last updated by GorLexx 2 years, 8 months ago.

Разрешение экрана монитора ПК (системы)- 1920х1080
Разрешение экрана смартфона (5″) – 1920х1080

Стримминг без 3Д – всё отлично, всё без искажений.
Стримминг с 3Д (фейковое или настоящее игровое) – искажение пропорций.

Trinus пишет сообщение- вывод 960х960, несоответствие пропорций.
В игре, например Doom 3 или Wolfenstein®: The New Order выбираю разрешение, которое меньше всего искажает пропорции – 1280х960, картинка вот такая, можно заметить сжатие по горизонтали на экране смартфона.
http://s40.radikal.ru/i089/1507/d6/7f02d147d661.png

Подскажите, как правильно настроить разрешение экрана, что-то я запутался.

Привет. Разрешение должно соответствовать 8:9, чтобы искажений не было совсем. Т.е. В вашем случае 960х1080 или 800х900. Если вы обладатель видео карты Nvidia, то в настройках видеокарта можно добавить нестандартное разрешение. Затем, выбрать его в игре, если разработчик игры об этом позаботился. Есть сторонние программы типа DXWND.Если не ошибаюсь, ATI с недавно времени тоже умеют добавлять не стандартное разрешение.
Если эти способы вам не помогают, выбирайте разрешение, с соотношением сторон 4:3. Искажения в таком случае будут, но незначительные

Понял, спасибо. Я затупил на этапе выбора разрешения- карта Nvidia (GTX580), добавил нестандартное разрешение и пытался запустить с ним систему на ПК, а не просто выбрать в игре. Всё, понял в чем ошибка, спасибо ?

У меня вопрос Nvidia Game Streaming может прогонять более 1080?
Все пишут что 2к лучше, но живых отзывов не нашлось…

oddsheepgames.com

Часть 1: Обзор

Я заметил, что для объяснения кодовой базы использую всё больше и больше иллюстраций и меньше текста. Раньше я пользовался для этого gliffy, но у него есть раздражающие ограничения (например, отсутствие альфа-канала). Я подумываю над созданием собственного инструмента на основе SVG и Javascript специально для иллюстраций по 3D-движкам. Интересно, есть ли уже что-то подобное? Ну да ладно, вернёмся к коду…

Очень приятно получить доступ к исходному коду такого потрясающего движка. В момент выхода в 2004 году Doom III задал новые графические и звуковые стандарты для движков реального времени, самым примечательным из которых стал «Unified Lighting and Shadows». Впервые технология позволила художникам выразить себя с голливудским размахом. Даже восемь лет спустя первая встреча с HellKnight в Delta-Labs-4 по-прежнему выглядит невероятно зрелищно:

Первый контакт

Исходный код теперь распространяется через Github и это хорошо, потому что FTP-сервер id Software почти всегда лежал или был перегружен.

Оригинальный релиз TTimo нормально компилируется с помощью Visual Studio 2010 Professional. К сожалению, в Visual Studio 2010 «Express» отсутствует MFC и поэтому её нельзя использовать. После релиза это несколько разочаровало, но с тех пор зависимости были удалены.

git clone https://github.com/TTimo/doom3.gpl.git

Для чтения и исследования кода я предпочитаю использовать XCode 4.0 в Mac OS X: скорость поиска из SpotLight, подсвечивание переменных и «Command-Click» для перехода к нужному месту делают работу удобнее, чем в Visual Studio. Проект XCode при релизе был сломан, но его очень просто исправить, и теперь есть репозиторий Github пользователя «bad sector», который хорошо работает на Mac OS X Lion.

git clone https://github.com/badsector/Doom3-for-MacOSX-

Примечания: оказалось, что подсветка переменных и переход по «Control-Click» также доступны и в Visual Studio 2010 после установки Visual Studio 2010 Productivity Power Tools. Не понимаю, почему этого нет в «ванильном» пакете установки.

Обе кодовые базы теперь находятся в наилучшем состоянии: для сборки исполняемого файла достаточно одного щелчка!

  • Скачайте код.
  • Нажмите F8 / Command-B.
  • Можно запускать!
  • Интересный факт: для запуска игры вам понадобится папка base с ресурсами Doom 3. Я не хотел тратить время на их извлечение с компакт-дисков Doom 3 и обновление, поэтому скачал версию со Steam. Кажется, ребята из id Software сделали так же, потому что в настройках отладки опубликованного проекта Visual Studio до сих пор есть «+set fs_basepath C:\Program Files (x86)\Steam\steamapps\common\doom 3» !

    Интересный факт: Движок был разработан в Visual Studio .NET (исходники). Но в коде нет ни одной строки на C#, а опубликованная версия для компиляции требует Visual Studio 2010 Professional.

    Интересный факт: Похоже, что команда Id Software — фанаты франшизы «Матрица»: рабочее название Quake III было «Trinity», а у Doom III рабочим названием было «Neo». Это объясняет, почему весь исходный код находится в подпапке neo .

    Архитектура

    Игра разделена на проекты, отражающие общую архитектуру движка:

    Как и во всех других движках, начиная с idTech2, мы видим один двоичный файл с закрытыми исходниками (doom.exe) и одну динамическую библиотеку с открытым исходным кодом (gamex86.dll):

    Большая часть кодовой базы была доступна с октября 2004 года в Doom3 SDK, отсутствовал только исходный код исполняемого файла Doom3. Моддеры могли собрать idlib.a и gamex86.dll , но ядро движка было пока закрыто.

    Примечание: Движок не использует стандартную библиотеку C++: все контейнеры (map, список с указателями. ) реализованы заново, но активно используется libc .

    Примечание: В модуле Game каждый класс наследует idClass. Это позволяет движку выполнять внутренний RTTI и создавать экземпляры классов по имени класса.

    Интересный факт: Если посмотреть на иллюстрацию, то можно заметить, что некоторые необходимые фреймворки (такие как Filesystem ) находятся в проекте Doom3.exe. Это представляет проблему, потому что gamex86.dll должна загружать и ресурсы. Эти подсистемы динамически загружаются библиотекой gamex86.dll из doom3.exe (вот что обозначает стрелка на иллюстрации). Если открыть DLL в PE explorer, то можно увидеть, что gamex86.dll экспортирует один метод: GetGameAPI :

    Всё работает точно так же, как Quake2 загружал рендерер и игровые ddl, передачей указателей на объекты:

    Когда загружается Doom3.exe, он:

  • Загружает DLL в пространство памяти процесса с помощью LoadLibrary .
  • Получает адрес GetGameAPI в dll с помощью GetProcAddress win32.
  • Вызывает GetGameAPI .
  • В конце этой «установки связи» Doom3.exe есть указатель на объект idGame , а в Game.dll есть указатель на объект gameImport_t , содержащий дополнительные ссылки на все отсутстующие подсистемы, например idFileSystem .

    Как Gamex86 видит объекты исполняемого файла Doom 3:

    Как Doom 3 видит объекты Game/Modd:

    Примечания: отличный ресурс для лучшего понимания каждой подсистемы — страница документации Doom3 SDK: похоже, она написана в 2004 году человеком с глубоким пониманием кода (то есть, скорее всего, одним из команды разработки).

    Перед разбором приведём немного статистики из cloc :

    2180 text files.
    2002 unique files.
    626 files ignored.

    http://cloc.sourceforge.net v 1.56 T=19.0 s (77.9 files/s, 47576.6 lines/s)

    ——————————————————————————-
    Language files blank comment code
    ——————————————————————————-
    C++ 517 87078 113107 366433
    C/C++ Header 617 29833 27176 111105
    C 171 11408 15566 53540
    Bourne Shell 29 5399 6516 39966
    make 43 1196 874 9121
    m4 10 1079 232 9025
    HTML 55 391 76 4142
    Objective C++ 6 709 656 2606
    Perl 10 523 411 2380
    yacc 1 95 97 912
    Python 10 108 182 895
    Objective C 1 145 20 768
    DOS Batch 5 0 0 61
    Teamcenter def 4 3 0 51
    Lisp 1 5 20 25
    awk 1 2 1 17
    ——————————————————————————-
    SUM: 1481 137974 164934 601047
    ——————————————————————————-
    По количеству строк кода обычно ничего определённого сказать нельзя, но здесь оно будет очень полезно для оценки труда, необходимого для понимания движка. В коде 601 047 строк, то есть движок в два раза «сложнее» для понимания, чем Quake III. Немного статистики об истории движков id Software в количестве строк кода:

    Примечание: Значительное увеличение объёма в idTech3 возникло из-за инструментов из кодовой базы lcc (компилятор C использовался для генерирования байт-кода QVM).

    Примечание: Для Doom3 инструменты не учитываются, потому что они вошли в кодовую базу движка.

    На высоком уровне можно заметить пару забавных фактов:

  • Впервые в истории id Software код написан на C++, а не на C. Джон Кармак объяснил это в интервью.
  • В коде активно используются абстрагирование и полиморфизм. Но интересный трюк позволяет избежать снижения производительности vtable на некоторых объектах.
  • Все ресурсы хранятся в человекочитаемом текстовом формате. Больше никаких двоичных файлов. В коде активно используется лексический анализатор/парсер. Джон Кармак рассказал об этом в интервью.
  • Шаблоны используются в низкоуровневых вспомогательных классах (в основном в idLib), но никогда не применяются на верхних уровнях, поэтому код, в отличие от Google V8, не заставляет глаза кровоточить.
  • С точки зрения комментирования это вторая по качеству кодовая база id software, лучше только Doom iPhone, возможно потому, что она вышла позже Doom3. 30% комментариев — по-прежнему выдающийся результат, очень редко можно найти так хорошо задокументированный проект! В некоторых частях кода (см. раздел о dmap) комментариев больше, чем кода.
  • ООП-инкапсуляция сделала код чище и упростила его чтение.
  • Дни низкоуровневой ассемблерной оптимизации прошли. Некотоорые трюки, например, idMath::InvSqrt и оптимизации пространственной локализации сохранились, но в основном код просто использует доступные инструменты (GPU-шейдеры, OpenGL VBO, SIMD, Altivec, SMP, оптимизации L2 ( R_AddModelSurfaces для обработки моделей). ).
  • Интересно также взглянуть на Стандарт написания кода idTech4 (зеркало), написанный Джоном Кармаком (в особенности я благодарен для комментарии о расположении const ).

    Разворачиваем цикл

    Вот анализ основного цикла с самыми важными частями движка:

    Подробнее о полностью разобранном цикле можно здесь. При чтении кода я использовал его как карту.

    Это стандартный для движков id Software цикл main. За исключением Sys_StartAsyncThread , который означает, что Doom3 многопоточный. Задача этого потока — управление критичными по времени функциями, которые движок не должен ограничивать частотой кадров:

  • Микширование звука.
  • Генерирование вводимых пользователем данных.
  • Интересный факт: все высокоуровневые объекты idTech4 являются абстрактными классами с виртуальными методами. Обычно такое снижает производительность, потому что адрес каждого виртуального метода перед его вызовом во время выполнения необходимо найти во vtable. Но есть «трюк», позволяющий этого избежать. Экземпляры всех объектов создаются статически следующим образом:

    Поскольку объект, статично размещаемый в сегменте данных, имеет известный тип, то компилятор может оптимизировать поиск во vtable при вызове методов commonLocal . При установке связи (handshake) используется указатель интерфейса, поэтому doom3.exe может обмениваться ссылками на объекты с gamex86.dll , но в таком случае затраты на поиск во vtable не оптимизируются.

    Интересный факт: изучив большинство движков id Software, я считаю примечательным то, что одно название метода НИКОГДА не менялось со времени движка doom1: метод, занимающийся считыванием вводимых с мыши и джойстика данных по прежнему называется IN_frame() .

    Две важные части:

    Поскольку в Doom3 используется система порталов, инструмент предварительной обработки dmap совершенно отличается от традиционного компоновщика bsp. Я рассмотрел его ниже, в соответствующем разделе.


    Рендерер времени выполнения имеет очень интересную архитектуру. Он разбит на две части с фронтэндом и бекэндом (подробнее об этом в разделе «Рендерер» ниже).

    Профилирование

    Я использовал Instruments из Xcode, чтобы проверить, чем занимаются циклы ЦП. Результаты и анализ см. в разделе «Профилирование» ниже.

    Скриптинг и виртуальная машина

    В каждом продукте idTech ВМ и скриптовый язык полностью менялись… и id сделала это снова (подробнее в разделе «Скриптовая ВМ»)

    Во время чтения кода меня озадачили некоторые нововведения, поэтому я написал Джону Кармаку и он был так любезен, что ответил и подробно объяснил следующие особенности:

    • C++.
    • Разбиение рендерера на две части.
    • Текстовые ресурсы.
    • Интерпретируемый байт-код.
    • Кроме того, я собрал на одной странице все видео и интервью с прессой об idTech4. Все они собраны на странице интервью.

      Часть 2: Dmap

      Как и во всех движках id Software, создаваемые командой дизайнеров карты проходят мощную предварительную обработку утилитой для увеличения производительности во время выполнения.

      В idTech4 эта утилита называется dmap и её цель заключается в считывании супа из многогранников из файла .map , определении областей, соединённых порталами и сохранении их в файле .proc .

      Цель этого инструмента — применение системы порталов времени выполнения в doom3.exe . Существует потрясающая статья Сета Теллера 1992 года: «Visibility Computations in Densely Occluded Polyhedral environment». В ней подробно и со множеством иллюстраций описывается то, как работает движок idTech4.

      Дизайнеры создают карты уровней с помощью CSG (Constructive Solid Geometry): они используют многогранники, обычно имеющие шесть граней, и размещают их на карте.

      Эти блоки называются «кистями» (brush). На рисунке ниже использовано восемь кистей (Для объяснения каждого шага dmap я буду использовать одну и ту же карту).

      Дизайнер может хорошо понимать, что находится «внутри» (первый рисунок), но dmap получает всего лишь суп из кистей, в котором нет ничего внутреннего и наружного (второй рисунок).

      Кисть определяется не через грани, а через плоскости. Задание плоскостей вместо граней может казаться неэффективным, но это будет очень полезно позже, при проверке того, находятся ли две поверхности на одной плоскости. Нет внутренних и внешних частей, потому что плоскости не ориентированы «одинаково». Ориентация плоскостей может быть разной внутри или снаружи объёма.

      Обзор кода

      Исходный код Dmap очень хорошо откомментирован, просто посмотрите на это количество: комментариев больше, чем кода!

      0. Загрузка геометрии уровня

      Файл .map — это список сущностей. Уровень — это первая сущность в файле, имеющая класс «worldspawn». Сущность содержит список примитивов, которые почти всегда являются кистями. Остальные сущности — это источники света, монстры, точки спауна игрока, оружие и т.д.

      Каждая кисть описывается как множество плоскостей. Стороны кисти называются гранями (или изгибами), каждая из которых получается обрезкой плоскости всеми другими плоскостями кисти.

      Примечание: на этапе загрузки используется очень интересная и быстрая система хэширования плоскостей (Plane Hashing System): поверх idHashIndex создана idPlaneSet , на которую стоит посмотреть.

      1. MakeStructuralBspFaceList и FaceBSP

      Первый этап — это разрезание карты способом двоичного разбиения пространства (Binary Space Partition). Каждая непрозрачная грань карты используется как разделительная плоскость.

      Используется следующая эвристика выбора разделителя:

      1: если в карте больше 5000 единиц: разрезаем с помощью ориентированной по осям плоскости (Axis Aligned Plane) посередине пространства. На рисунке ниже пространство 6000×6000 разрезано три раза.

      2: Когда больше не осталось частей больше 5000 единиц: используем грани, помеченные как «порталы» (они имеют материал textures/editor/visportal ). На рисунке ниже кисти порталов отмечены голубым.

      3: Используем оставшиеся грани. Выбираем грань, наиболее коллинеарную с большинством других И разрезаем наименьшие грани. Также предпочтение отдаётся осевым разделителям. Разделительные плоскости отмечены красным.

      Процесс завершается, когда не остаётся доступных граней: весь лист BSP-дерева представляет собой выпуклое подпространство:

      2. MakeTreePortals

      Теперь карта разделена на выпуклые подпространства, но эти подпространства ничего не знают друг о друге. Цель этого этапа — соединить каждый из листьев с его соседями с помощью автоматического создания порталов. Идея заключается в том, чтобы начать с шести порталов, ограничивающих карту: соединить «внешнее» с «внутренним» (с корнем BSP). Затем для каждого узла в BSP разделяем каждый портал в узле, добавляем разделительную плоскость в качестве портала и рекурсивно повторяем.

      Шесть исходных порталов будут разделены и распространятся вниз, к листьям. Это не так тривиально, как кажется, потому что каждый раз узел разделяется: каждый присоединённый к нему портал тоже должен быть разделён.

      На рисунке слева один портал соединяет два узла-«брата» в BSP-дереве. При следовании по левому дочернему листу его разделительная плоскость делит портал на два. Мы видим, что порталы других узлов тоже нужно обновлять, чтобы они больше не соединялись с «братьями» и их «племянниками».

      В конце процесса шесть исходных порталов разделены на сотни порталов, а на разделительных плоскостях созданы новые порталы:

      Каждый лист в BSP теперь знает о своих соседях благодаря связанному списку порталов, присоединяющих их к листьям, имеющим общее ребро:

      3. FilterBrushesIntoTree

      Этот этап похож на детскую игру с подбором форм фигур, где BSP — это доска, а кисти — это фигуры. Каждая кисть отправляется вниз по BSP для обнаружения непрозрачных листьев.

      Способ работает благодаря хорошо описанной эвристике: если кисть немного пересекает разделительную плоскость, но не больше, чем на EPSILON, то онВместо этого она полностью отправляется на сторону плоскости, на которой находятся все другие элементы кисти.

      Теперь «внутренние» и «внешние» части начинают быть видимыми.

      Лист, которого коснулась кисть, считается непрозрачным (сплошным) и соответственным образом помечается.

      4. FloodEntities и FillOutside

      С помощью сущности спауна игрока для каждого листа выполняется алгоритм заливки. Он помечает листья как достижимые сущностями.

      Последний этап FillOutside проходит по каждому листу и если он недостижим, то помечает его как непрозрачный.

      Мы получили уровень, в котором каждое подпространство или достижимо, или непрозрачно: теперь навигация через порталы листьев единообразна и выполняется проверкой целевого листа на непрозрачность.

      5. ClipSidesByTree

      Настало время отбросить ненужные части кистей: каждая исходная сторона кисти отправляется вниз по BSP. Если сторона находится внутри непрозрачного пространства, то она отбрасывается. В противном случае она добавляется в список visibleHull стороны.

      В результате мы получаем «кожу» уровня, сохраняются только видимые части.

      С этого момента для оставшихся операций рассматривается только список visibleHull стороны.

      6. FloodAreas

      Теперь dmap группирует листья с идентификаторами областей: для каждого листа выполняется алгоритм заливки. Он пытается залить всё через порталы, связанные с листом.

      Здесь работа дизайнера имеет огромную важность: области можно идентифицировать, только если на карте были вручную расположены visportals (кисти порталов, упомянутые на этапе 1). Без них dmap идентифицирует только одну область и каждый кадр в видеопроцессор будет отправляться вся карта.

      Рекурсивный алгоритм заливки останавливается только порталами областей и непрозрачными узлами. На рисунке ниже автоматически сгенерированный портал (красный) позволит продолжить заливку, но размещённый дизайнером visportal (синий, также называется areaportal), остановит его, создав две области:

      В конце процесса каждый несплошной лист принадлежит к области и определены межобластные порталы (голубой).

      7. PutPrimitivesInAreas

      На этом этапе в ещё одной игре «Найди фигуру» сочетаются области, определённые на этапе 6 и visibleHull, вычисленный на этапе 5: на этот раз доска — это области, а фигуры — это visibleHull.

      Выделяется массив областей и каждый visibleHull каждой кисти отправляется вниз по BSP: к массиву областей добавляются поверхности по индексным areaID.

      Примечание: довольно умный ход — на этом этапе также оптимизируется спаунинг сущностей. Если некоторые сущности помечены как «func_static», их экземпляры создаются сейчас и привязываются к области. Таким образом можно «приклеить» ящики, бочки и стулья к области (также выполнив предварительную генерацию их теней).

      8. Prelight

      Для каждого статичного источника света dmap предварительно вычисляет геометрию объёмов теней. Эти объёмы позже как есть сохраняются в .proc . Единственная хитрость заключается в том, что объёмы теней сохраняются с именем «_prelight_light» , соединённым с идентификатором источника света, чтобы движок мог сопоставить источник света из файла .map и объём теней из файла .proc :

      9. FixGlobalTjunctions

      Исправление Т-образных соединений обычно важно для избавления от визуальных артефактов, но в idTech4 оно ещё важнее: геометрия также используется для генерирования теней в процессе записи в буфер шаблонов. Т-образные соединения дважды проблемны.

      10. Вывод данных

      В конце все предварительно обработанные данные сохраняются в файл .proc :

    • Для каждой области множество граней поверхностей группируется по материалу.
    • BSP-дерево с areaID для листьев.
    • Изгибы межобластных порталов.
    • Объёмы теней.
    • Многие сегменты кода из dmap схожи с кодом, использованным в инструментах предварительной обработки Quake ( qbsp.exe ), Quake 2 ( q2bsp.exe ) и Quake 3 ( q3bsp.exe ). Причина этого в том, что потенциально видимое множество (PVS) сгенерировано с помощью временной системы порталов:

    • qbsp.exe считывал .map и генерировал файл .prt , содержащий информацию о связях между листьями в порталах BSP (в точности как на этапе 2 «MakeTreePortals»).
    • vis.exe использовался в .prt в качестве входа. Для каждого листа:
      • выполнялась заливка с помощью порталов в связанные листья.
      • перед заливкой в лист: выполнялась проверка видимости отсечением следующего портала с двумя предыдущими порталами относительно пирамиды видимости (многие считали, что видимость определяется испусканием тысяч лучей, но это миф, в который много кто верит и сейчас).
      • Иллюстрация всегда лучше: допустим qbsp.exe обнаружил шесть листьев, соединённых порталами и теперь выполняется vis.exe для генерирования PVS. Этот процесс будет выполнен для каждого листа, но в этом примере мы рассмотрим только лист 1.

        Так как лист всегда видим из самого себя, то первоначальное PVS для листа 1 будет следующим:

        m.habr.com

        Смотрите так же:

        • Сайт урайский городской суд Судебный участок № 1 Урайского судебного района Постановлением председателя Урайского городского суда Джилакановой З.М. от 05.09.2017 исполнение обязанностей мирового судьи судебного участка № 1 Урайского судебного района Юриновой Елены Викторовны в связи с ее временным отсутствием в […]
        • Сумма заработка за 2013 год для расчета пособия Считаем больничный в 2014 году Денис Ефименко, эксперт по финансовому законодательству В 2014 году бухгалтер должен брать для расчета размера пособия по временной нетру­до­способности суммарный за­ра­бо­ток сотрудника, облагаемый страхо­выми взносами в ФСС Рос­сии, за 2012 и 2013 годы. […]
        • Пенсия средняя врача Пенсии в СССР. Просто факты. Пенсия в 32 рубля. Была назначена в 1975 году одной из моих бабушек. Общий (прерывный) стаж - немногим более 11 лет. Зарплата за последние 8 лет 100-110 рублей.Пенсия в 45 рублей. Была назначена в 1967 году. Это вторая бабушка. С 1930-х годов работала […]
        • Статьи 159 и 160 ук рф Ст 160 УК РФ мошенничество, что грозит? Я работала в ООО фирме кредитования оформляя займы на людей с семейными трудностями. На протяжении полугода составляла договора на несуществующих людей и паспортные данные, по действующим этим договорам шли % и чтобы скрыть это закрывала договор и […]
        • Наказание женщин в пакистане Spynet.ru самый развлекательный 4 читателя 0 топиков Прямой эфир stringer1977 → Лучшие гифки 10 в Картинки stringer1977 → Москва удивляет своими ценами на "убитое" жилье 10 в Общий alisanevazhn → Ferrari part №1 24 в Тачки pinuskabesr → Ярость велосипедиста (видео) 3 в Картинки […]
        • Литература по арбитражным судам Литература по арбитражным судам Один @ втор.ru Самара 8-927-902-39-25 Дипломные, курсовые, контрольные работы на заказ в Самаре [email protected] Список литературы по арбитражному процессу На этой странице приведен список литературы по арбитражному процессу: 1. Арбитражный […]
        • К фельдшеру обратился мужчина 32 лет с жалобами на сильный кожный зуд Руфут.ру - развлекательный сайт Автор записи: Пользователь удален Вопрос: К фельдшеру обратился мужчина 32 лет, с жалобами на сильный кожный зуд, появление волдырей по всему телу. Заболевание связывает с употреблением рыбы. Болен 2-й день.Объективно: температура 37,10С. […]
        • Общая собственность дипломная Общая собственность: понятие, виды, основания возникновения Курсовая работа Выполнена в 2017 году, 46 страниц, 31 сноска Содержание Введение 3 Глава 1 Понятие и сущность общей собственности 5 1.1 Понятие общей собственности 5 1.2 Виды общей собственности и их особенности 7 1.3. Коллизии […]