RU/GTA:SA Resource Streaming: Difference between revisions
No edit summary |
No edit summary |
||
| (One intermediate revision by the same user not shown) | |||
| Line 96: | Line 96: | ||
В MTA:Eir, поддержка моделей была исправления предложением ресурсов модели на базовой информации о ней и предотвращением удаления пользовательских коллизий когда COL секторы были выгружены. | В MTA:Eir, поддержка моделей была исправления предложением ресурсов модели на базовой информации о ней и предотвращением удаления пользовательских коллизий когда COL секторы были выгружены. | ||
== | ==Идеи для Расширения== | ||
Изначально, загрузчик не работает с достаточной эффективностью. Как сказано выше, система имитирует поведелние сопрограммы. Если очень большие .DFF модели были загружены, система стриминга будет вызывать падения FPS. Путь загрузки текстурных контейнеров не является совершенным, даже если их загрузка разделена на два толчка. В теории преобразование каждой текстуры в игровой экземпляр является сложной задачей. С самого начала, стриминг не зависит от времени процесс загрузки. Если бы это было, то система может отказывать когда TXD контейнер занимает слишком много времени для загрузки. | |||
Мое продложение заключается в том, чтобы какждый слайсер получил файбер в MTA менеджере. В каждом кадре (и во всех других вероятных мементах) все файберы были обновлены, таким образом обеспечивая загрузку ресурса. Так каждый файбер обеспечивает свой стек выполнения, что избегает сложного кода. Когда определенная часть данных прочитана из RenderWare потока, выполнение файбера обрывается. Такое изменение загрузки ресурсов сделает сглаженным FPS GTA:SA во время пересечения мира. | |||
Проблемы с этим предложеним находится в том, что RenderWare функции стриминга присоединены к сетевому модулю. | |||
===Fibered | ===Fibered Загрузка=== | ||
Эта техника используется в MTA:Eir для увеличения произвольности на слабых компьютерах. Как правило, он сглаживает количество FPS игры удалением острых лагов. В стандартной GTA:SA, ресурсы в основном загружаются одномоментно. С другой стороны, используя [[MTA:Eir/functions/engineStreamingSetFiberedLoadingEnabled|fibered loading]], загрузка ресурсов зависит от времени за которое Система стриминга может занимать в каждом кадре. Время которое может потребоваться, получается из общего времени выполнения последнего кадра. | |||
Предполагается, что очень большие TXD контейнеры хранятся в GTA3.IMG. Такие ресурсы забирают относительно много времени на буферизацию в игровую память и попытка инициализации пока стриминг загружается, может привести к лагам потому что все данные обрабатываются сразу. Если fibered загрузка включена, сопрограмма (т.н. fiber) создается для каждой ''слайсера'' загрузки ресурса с его исполнительным стеком. Когда загрузчик пытается прочесть ресурсы из буфера, исполнительный менеджер fiber'а проверяет был ли уже взят [[MTA:Eir/functions/engineStreamingSetFiberedPerfMultiplier|он в свое время]]. Если да, он останавливается во время процесса чтения. Выполнение будет продолжено в следующем игровом кадре. | |||
[[en:GTA:SA_Resource_Streaming]] | [[en:GTA:SA_Resource_Streaming]] | ||
Latest revision as of 15:58, 27 May 2014
Система GTA:SA Resource Streaming загружает данные из диска в игровую память. Она разделена на управление IMG контейнером, потоковым чтением ресурсов, преобразованием в игровые объекты, загрузка сектора COL/IPL и игровую логику. Она была создана для асинхронной загрузки ресурсов.
Известные типы ресурсов
| Имя | ID диапазон | Описание |
|---|---|---|
| Модели (.DFF) | 0-19999 | Все игровые модели входят в эти ID. Внутренне этот диапазон дальше разделяется на подсекции объектов, автомобилей и педов. |
| Текстурные Словари (.TXD) | 20000-24999 | Содержит слоты текстурных словарей. Текстурные словари это контейнеры со всеми игровыми текстурами. Игра присваивает текстурные словари к моделям. |
| Секторы Столкновений (.COL) | 25000-25255 | Слоты хранят все загруженные секторы столкновений. Секторы столкновений это COLL контейнеры, которые могут ссылаться и простираться через внутриигровые границы (основано на зданиях, которые используют их). |
| IPL Секторы (.IPL) | 25256-25510 | Слоты содержат все загруженные IPL секторы. IPL секторы представлены бинарными .ipl файлами внутри .IMG контейнера. Игра загружает их внуть своих рамок только когда они будут необходимы. |
| Контейнеры Патчнодов (.DAT) | 25511-25574 | Патчноды выровнены на секторы 8*8 по 750*750 юнитам. Когда игра ссылаться на такой квадрат, она загружает связанные файлы патчнодов, которые нумерованы в соответствии с формулой (height * rowLen + rowIndex). |
| Блоки Анимаций (.IFP) | 25575-25754 | Блоки анимации содержат все последовательности анимаций. Модели могут ссылаться на анимационные блоки, поэтому они запрашивают их вместе. |
| Записи (.RRR) | 25755-25819 | Записи хранят предварительно записанные данные игровых движений. Эти игровые движения используются во время миссий когда вы гонитесь за кем-то или прицеливаетесь из окна пока друг ведет. |
Описание
Управление IMG Контейнером
Во время инициализации движка, игра загружает файлы конфигурации, которые говорят ему какие .IMG контейнеры использовать. Когда Система стриминга инициализирована, она пытается загрузить зарегистрированные .IMG контейнеры. Каждый .IMG контейнер ссылается используя уникальный индекс внтури IMGFile массива. Игра держит открытыми хэндлы файлов .IMG контейнеров, так что она может всегда читать из них.
Когда .IMG контейнер будет загружен, каждый файл может представить новый ID ресурса внутри движка (структура CModelInfoSA). Модели получат ID путем сравнением их имен с .IDE записью. Если ничего не найдено, движок поддерживает небольшой кэш ресурса. Эти ресурсы еще могут быть загружены используя RequestSpecialModel. Текстурный Словарь получает новый ID. Имеется жесткий лимит в 5000 TXD. COLL и IPL секторы также получают новые ID основанные на порядке загрузки. Все остальные ресурсы поступают также, следую этим же принципам.
Внутренний CModelInfoSA массив представляет каждую запись ресурса в .IMG файлах. Движок поддерживает всего 26310 ресурсных ID.
Возможные состояния загрузки ресурса
| Имя | Описание |
|---|---|
| MODEL_UNAVAILABLE | Ресурс не был загружен. Ни один из игровых ресурсов для этой записи не был загружен. Этот ресурс не используется ни одной из частей игрового движка. |
| MODEL_LOADED | Этот ресурс был загружен Системой стриминга. Он готов быть использован игровым движком. |
| MODEL_LOADING | Этот ресурс находится в очереди быть-загруженным. Он ожидает взятия Системой стриминга для чтения с диска. |
| MODEL_QUEUE | Слайсер в настоящее время читает данные из диска для этого ресурса. |
| MODEL_RELOAD | Этот ресурс в настоящее время загружается в сопрограмму. Данные которые с ним связаны слишком большие чтобы загрузить их сразу же. |
(Поточность) Чтение Ресурсов
Существует совершенно отдельная система просто для чтения порций данных с диска, известная как streaming runtime. Игра может создавать потоковые хэндлы для файлов на диске. При вызове функции ReadStream, будет сделан запрос на чтение данных из потокового хендла. Процесс чтения обеспечивается структурами syncSemaphore которые удерживают внутренние данные о процессе чтения (такие как хэндл файла или структуры OVERLAPPED). Вызов GetSyncSemaphoreStatus c индексом syncSemaphore в качестве аргумента будет возвращать статус запроса (т.е. чтение завершено). CancelSyncSemaphore останавливает любые асинхронные запросы.
Во время старта, система проверяет возможности системы. По умолчанию, поточность включена. Для проверки поддержки этого, предпринимается попытка чтения из GTA3.IMG используя перекрытый ВВОД/ВЫВОД. Система выберет наилучшую совместимую конфигурацию. На современных машинах, это значит поточность с перекрытым ВВОДОМ/ВЫВОДОМ. В случае худшего сценария, игра читает данные синхронно в одиночном потоке с остановкой выполнения игры, если данные читаются из медленного медиа-хранилища.
Преобразование в Объекты Движка
Система стриминга изначально обеспечивает два читающих слайсера. Читающий слайсер проверяет какие запрашиваемые данные ближе в .IMG контейнере и сразу читает несколько одномоментно. Модифицируя логику движка можно ввести поддержку произвольного числа слайсеров, которые все будут делиться порциями внутри буфера чтения. Чем больше слайсеров, тем меньше секция буфера чтения для каждого. Если прочитанные данные не входят в один слайсер, Система стриминга ждет завершения всех небольших запросов и тогда читает большие данные в первом слайсере используя весь буфер чтения. Размер буфера чтения определяется наибольщим ресурсом внтури всех зарегистрированных .IMG контейнеров.
Существует 4 состояния, которые могут иметь слайсеры: простой, буферизация, загрузка и ожидание. Слайсеры с простоем ждут запроса, который может занять их. Когда слайсеры буферизируются, они ждут до конца свои запросы чтения. Слайсеры загрузки ждут пока игра загрузит все игровые ресурсы из них. Ожидание является исключительным статусом, который появляется если слайсер запрошен на передачу данных для преобразования объекта движка, но запрос чтения еще не завершен.
Загрузка самый интересный статус. Слайсер ложит необработанные данные в процедуру загрузчика вместе с их ID модели. Используя ID модели, движок знает как эти сырые данные должны быть представлены. Например, модель с id 1361 это ресурс модели, который хранится в .DFF файле. Процедуры загрузчика обычно загружают данные одномоментно. Если найденные данные слишком большие, они будут загружены несколькими толчками слайсера (слайсер находится в состоянии загрузка). Затем данные будут обработаны в сопрограмме. Изначально, только текстурные словари которые превышают определенное количество блоков используют эту возможность. Также, движок был оптимизирован считать что все данные загружаются в двух толчках слайсеров (максимально).
Каждый слайсер имеет свой syncSemaphore из streaming runtime. Индекс syncSemaphore соответствует индексу слайсера.
Загрузка Сектора COL/IPL
GTA:SA движок сопоставляет COLL и IPL секторы мировым координатам границ. Когда позиция стриминга (изначально позиция игрока) пересекается с любым сектором, он будет запрошен на загрузку. Эта работа обеспечивается в классе-шаблоне Sectorizer. Каждый COLL и IPL сектор добавляется в дерево квадрантов для ускорения обзора территории мира. Секторы выделяются из личного пула данных. Секторы имеют свой менеджер, которй специализируется на работе Sectorizer'ов (загрузка и выгрузка, преобразование индекса в id модели, логика маркировки сектора).
Игровая Логика
Когда камера приближается к земле, Система стриминга обновляет толчком игровое окружение. Оно выполняет предзагрузку моделей событий и стриминг зон событий. Эти возможности были отключены в МТА, но являются интересными если рассматривается поддержка одиночной игры.
Поддержка Мультиплеера
MTA:SA устанавливает высокие требования к движку GTA:SA. Система стриминга должна быть ключевым местом для загрузки ресурсов. Следовательно, изначально система не предполагает взаимодействия с внешними источниками, такими как MTA.
Для исправления этой проблемы, вся система должна быть разобрана и правильно расширена. Функции RequestModel и FreeModel используются для запроса ресурсов для каждого игрового экземпляра. Расширением этих функций, МТА может предложить пользовательские ресурсы игровому движку (т.е. модели и коллизии). Простого ASM хука недостаточно, потому что код требует тяжелой настройки которая должна быть понятна для каждого MTA разработчика. Например, для предотвращения утечек памяти и нестабильности, работа Поточного слайсера и очередь загрузчика должны быть настроены в соответствии с тем как MTA манипулярует статусами ресурса.
В MTA:Eir, поддержка моделей была исправления предложением ресурсов модели на базовой информации о ней и предотвращением удаления пользовательских коллизий когда COL секторы были выгружены.
Идеи для Расширения
Изначально, загрузчик не работает с достаточной эффективностью. Как сказано выше, система имитирует поведелние сопрограммы. Если очень большие .DFF модели были загружены, система стриминга будет вызывать падения FPS. Путь загрузки текстурных контейнеров не является совершенным, даже если их загрузка разделена на два толчка. В теории преобразование каждой текстуры в игровой экземпляр является сложной задачей. С самого начала, стриминг не зависит от времени процесс загрузки. Если бы это было, то система может отказывать когда TXD контейнер занимает слишком много времени для загрузки.
Мое продложение заключается в том, чтобы какждый слайсер получил файбер в MTA менеджере. В каждом кадре (и во всех других вероятных мементах) все файберы были обновлены, таким образом обеспечивая загрузку ресурса. Так каждый файбер обеспечивает свой стек выполнения, что избегает сложного кода. Когда определенная часть данных прочитана из RenderWare потока, выполнение файбера обрывается. Такое изменение загрузки ресурсов сделает сглаженным FPS GTA:SA во время пересечения мира.
Проблемы с этим предложеним находится в том, что RenderWare функции стриминга присоединены к сетевому модулю.
Fibered Загрузка
Эта техника используется в MTA:Eir для увеличения произвольности на слабых компьютерах. Как правило, он сглаживает количество FPS игры удалением острых лагов. В стандартной GTA:SA, ресурсы в основном загружаются одномоментно. С другой стороны, используя fibered loading, загрузка ресурсов зависит от времени за которое Система стриминга может занимать в каждом кадре. Время которое может потребоваться, получается из общего времени выполнения последнего кадра.
Предполагается, что очень большие TXD контейнеры хранятся в GTA3.IMG. Такие ресурсы забирают относительно много времени на буферизацию в игровую память и попытка инициализации пока стриминг загружается, может привести к лагам потому что все данные обрабатываются сразу. Если fibered загрузка включена, сопрограмма (т.н. fiber) создается для каждой слайсера загрузки ресурса с его исполнительным стеком. Когда загрузчик пытается прочесть ресурсы из буфера, исполнительный менеджер fiber'а проверяет был ли уже взят он в свое время. Если да, он останавливается во время процесса чтения. Выполнение будет продолжено в следующем игровом кадре.