Класс TD3D_GDOList - контейнер для всех графических объектов (нечто
аналогичное TSpriteEngine в DelphiX). Класс TD3D_GDOListItem - родитель объектов, помещаемых в контейнер TD3D_GDOList. Класс TD3D_GDOList сам произведен от TD3D_GDOListItem. Это даст возможность создавать вложенные списки, т.е. один контейнер может содержать список других контейнеров. Конечно увлекаться этой возможностью не стоит, т.к. быстродействие и ресурсы памяти не бесконечны... Но такая возможность есть!

================================================

Правила использования класса TD3D_GDOList

================================================

- В модуле приложения создать классы графических объектов, производные от класса TD3D_GDOListItem;

- В переопределенных методах и в методах с префиксом Do описать необходимую реализацию соотвествующей стадии
(создание контейнера, загрузка ресурсов, установка параметров, сброс параметров, удаление ресурсов,
удаление контейнера -
Create, DoInit, DoRestore, DoInvalidate, DoDelete, Destroy);

- В методе создания объекта приложения создать все необходимые объекты,
- создать объект с типом TD3D_GDOList
(соответствующее поле предварительно объявить внутри класса приложения)
- добавить созданные объекты в список объекта с типом TD3D_GDOList

- в соответствующих стадиях приложения вызывать методы объекта с типом TD3D_GDOList, т.е.
D3D_GDOList.Init...;
D3D_GDOList.Restore...;
D3D_GDOList.Invalidate...;
D3D_GDOList.Delete...;

D3D_GDOList.Render;
D3D_GDOList.FrameMove;

- в методе разрушения класса приложения вызвать метод разрушения
FreeAndNil(D3D_GDOList);
или SAFE_DELETE(D3D_GDOList); - оба они допустимы.

Функционирование приложения может быть таково, что не все объекты списка D3D_GDOList
должны отрисовываться в одно время. Например, вывод меню требует отрисовки одних
объектов, игровой процесс - других. Решением может быть создание нескольких списков,
содержащих нужные группы объектов. Если игровое меню на заднем плане отображает демо-
игровую сцену, то эта проблема отпадает вообще.

Для отдельных независимых объектов, требующих отрисовки в отдельное время, можно
непосредственно производить отрисовку прямым вызовом их методов Render и FrameMove в
нужных местах методов Render и FrameMove кода приложения. При этом вызов методов
D3D_GDOList.Render;
D3D_GDOList.FrameMove;
в данное время нужно опустить.

Рабочие заметки

======================================================================

Работа с объектами GDI (Graphic Device Interface) через DirectX требует для использования
следующих стадий -

возьмем любой класс для работы с GDI DX, например

TD3DImage2D
-------------------------
Вот необходимые стадии для инициализации, настройки объекта и управления необходимыми ресурсами (текстуры, модели, шейдеры и т.п.)

Создание контейнера объекта -
Some2DImage := TD3DImage2D.Create(TextureFormat);

Инициализация (загрузка необходимых ресурсов в память)
(InitDeviceObjects, CreateDeviceObjects)
Some2DImage.InitDeviceObjects(pd3dDevice, TextureFilename);

Установка необходимых параметров, создание буферов, программная генерация моделей (и т.п.)
Some2DImage.RestoreDeviceObjects;

Сигнал о нарушении установленных параметров и о необходимости их перенастройки
Some2DImage.InvalidateDeviceObjects;

Удаление ресурсов из памяти(DestroyDeviceObjects )
Some2DImage.DeleteDeviceObjects;

Удаление контейнера объекта
SAFE_DELETE(Some2DImage);

Кроме того, в методах D3D-приложения - Render и FrameMove вызываются необходимые методы
данного класса для отрисовки статичных и анимированных изображений.

Несомненно, что всё это увеличивает и усложняет исходный код.
Еще в DelphiX эта проблема решалась за счёт создания некоторого класса TSpriteEngine, который
собственно и выполнял все эти рутинные задачи.

Необходимо было только
- создать данный класс, пусть это будет TD3D_GDOList (D3D Graphic Device
Objects List)
- создать классы производные от него;

- создать классы в рабочем коде, добавить их в список TD3D_GDOList

- в рабочем коде вызывать методы данного класса в нужных стадиях.

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

Это позволит:
- разрабатывать графические объекты в виде отдельных классов, сосредоточившись на внутренней
реализации конкретного класса;
- сократить объем кода внутри объекта D3D-приложения;

Общий объем кода не сократится, т.к. будет перенесен внутрь каждого конкретного объекта,
сократится объем кода внутри объекта приложения.