RU/GTA:SA Streaming Garbage Collection

From Multi Theft Auto: Wiki
Revision as of 10:34, 27 May 2014 by TEDERIs (talk | contribs)
Jump to navigation Jump to search

Система GTA:SA Streaming Garbage Collection отслеживает использование игровой памяти. Она обеспечивает ограничение выделяемой на стриминг памяти для всего игрового движка. Память для стриминга рассчитывается сложением размера порции файла-ресурса каждого загруженного игрового ресурса. Когда лимит достигнут, система попытается высвободить место путем удаления ресурсов из игровых экземпляров. Если эта процедура не удалась, игровой движок повиснет (умышленно). Этот лимит может быть отрегулирован настройкой опции видеопамяти в ваших настройках видео.

Активные Потоковые Сущности

Full potencial of GTA:SA streaming.

Объекты, здания и даммисы которые имеют свои загруженные RenderWare ресурсы, будут добавлены в активный сборщик мусора сущностей. Как только он заработает, он начнет удалять RenderWare объекты всех зарегистрированных сущностей, которые находятся вне поля зрения или далеко. Если количество ссылок на модель достигло нуля, система освободит ресурс модели. Изначально, движок может обрабатывать до 1000 сущностей в его отсортированном контейнере (CRenderChainInterface <streamingChainInfo>). Если выделение узла контейнера не удалось, запрашивающая сущность уничтожит свои RenderWare данные. Следовательно, изначально только 1000 объектов, зданий или даммисов могут быть отрисованы в одно время. Неспособность выделить узлы контейнера часто была заметна на дальних дистанциях отрисовки (также известна как blinking building bug).

Разработчик MTA ccw это человек, который первый нашел blinking building bug.

Node Allocation Methods

There are multiple ways to allocate streaming nodes when they are not available anymore. Natively, the GTA:SA engine steals streaming nodes from the first entities it finds on the streaming garbage collection entity registry. This is why the world flickers wildly when it is out of available nodes.

A better way is to garbage collect the world on demand. This way only entities that are out of sight will lose their RenderWare data. The performance of this method depends on the nature of the registered streaming GC entities as well as the amount of registered entities.

If memory and GPU performance is not of concern, the engine can allocate new nodes into the system so that more entities can have their RenderWare data allocated on the world. This results in theoretically infinite entities visible on the screen.

While each method has its strong and weak points, the optimal way to stream the world is to switch between these methods at runtime. MTA:Eir will ship with a standard streaming_opt resource that will do this for you. The plan is that streaming nodes will be allocated depending on engine performance and demand.

Implementation differences between MTA versions

MTA:BLUE

The draw distance bug has been decimated in MTA:BLUE. The maximum number of managed streaming entities has been increased to 2500 to compensate for large drawing distances. That increases the engine performance a lot, as more streaming memory can be allocated by game entities.

MTA:Eir

In MTA:Eir, the drawing distance bug has been fixed, too. While the hardcoded maximum has been left at 1000 entities inside of the garbage collection system, when the limit has been reached, the system allocates new nodes into the sorted container. There is theoretically no limit to object, dummy and building streaming this way.

Multiple options have been added through scripting functions to change the streaming node allocation behavior. The flickering is no longer a bug, but a feature that can be disabled. Using scripting functions Lua scripts can retrieve the amount of nodes allocated and free to be allocated.

References