RU/GTA:SA Resource Streaming

Система 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 модели, логика маркировки сектора).

Игровая Логика

When the camera is close to the ground, the Streaming system pulses game activity management. Game activity is pre-loading of event models and streaming of event zones. These features have been disabled in MTA, but are interesting if SP support is considered.

Multiplayer Support

MTA:SA sets high demands for the GTA:SA engine. The streaming system was meant to be the central location to load resources from. Hence, natively, the system does not expect interaction of outside sources, such as the MTA runtime.

To fix this problem, the entire system has to be understood and properly expanded. The RequestModel function and the FreeModel function are used to request resources for every game instance. By expanding the logic of these functions, MTA can offer custom resources to the game engine (i.e. models and collisions). Simple ASM hooks are insufficient, as the code requires heavy adjustments which need to be clear to every MTA developer. For instance, to prevent memory leaks and instability, the Streaming slicer activity and the loader queue have to be adjusted according to how MTA manipulates the resource status.

In MTA:Eir, the model support has been fixed by offering model resources on base model info request and preventing the deletion of custom collisions when COL sectors are being unloaded.

Ideas for Expansion

Natively, the loader does not operate with perfect efficiency. As stated above, the system mimicks coroutine behavior. If very big .DFF models are loaded, the Streaming system can cause FPS drops. The way texture containers are loaded is imperfect, even if their loading is split into two pulses. The theory is that the conversion of every texture into a game instance is a complex task. Natively, streaming is not dependant on timing of the load process. If it were, then the system could yield when a TXD container takes too long to load.

My proposal is that every slicer obtains a fiber in a MTA execution manager. Once per frame (and at all other plausible moments) all fibers will be pulsed, thus progressing resource loading. Since every fiber maintains its own runtime stack, complex code is avoided. When a certain quota of data is read from a RenderWare stream, the fiber's execution is yielded. Such a change in resource loading is going to smoothen the FPS of GTA:SA when traveling across the world.

Problem with such a proposal is that the RenderWare streaming functions are hooked by the network module.

Fibered Loading

This is a technique utilized in MTA:Eir to improve the performance of low-end computers. It generally smoothens the FPS count of the game by removing lag-spikes. In native GTA:SA, resources are mostly loaded in one go. Using fibered loading on the other hand, loading of resources depends on the time the Streaming system may take per frame. The time it may take is derived from the total execution time of last frame.

Imagine that a very big TXD container is stored inside of GTA3.IMG. Such resources take a relatively long time to be buffered into game memory and an initialization attempt during Streaming loading may cause a lagspike, since much data is processed at once. If fibered loading is enabled, a coroutine (a.k.a. fiber) is created for every resource loading slicer with its own execution stack. When the loader attempts to read resources from the buffer, the fiber executive manager checks whether the fiber has taken its time already. If so, it yields during the read process. Execution will continue next game frame.