Класс Модификаторов (комментарии)

Класс Модификаторов (комментарии)

Это сообщение сгенерировано автоматически.

подумай над следующей мыслю:
- Делается глобальный список объектов:
Var
  GlobalObjectBANK: TObjectArray; //Хранилище объектов
Тогда хранилище объектов выносится из менеджера сцены и менеджер сцены практически ничем не обличается от модификатора и их можно написать однотипно, как у тебя написан модификатор
тогда
procedure TimeProc(uTimerID, uMessage: UINT;dwUser, dw1, dw2: DWORD) stdcall;
begin
APSceneMenager.UpdateObjects;
МodificatorMove.UpdateObjects;
SoundEngine.UpdateObjects;
И т.д.
end;

Привет! Спасибо за комент!
Первоначальная идея проекта была такая - во главе всей архитектуры стоял Менеджер Сцены. Планировалось, что он будет обладать всеми методами управления объектами
APSceneMenager.Move(IDObject:Cardinal);
APSceneMenager.Rotate(IDObject:Cardinal);
То есть предполагалось, что он будет выполнять обработку и отрисовку объектов. Только благодаря Lion007 я задумался над идеей делегирования этих функций отдельным классам-модификаторам. Создал один и посмотрел как с ним работать. Но интеграцию этих классов с Менеджером Сцены еще не производил, и перспективы получивщейся архитектуры тоже еще не продумал, но заметил, что у менеджера сцены и модификаторов есть что-то общее (в плане влияния на объекты. А идея хранилища объектов впринципе с самого начала подразумевала, что это хранилище для всех объектов, а для разных нужд будут создаваться другие вспомогательные списки ссылок (индексов) на эти объекты. Так например, в моем движке не используется тест глубины и все объекты отрисовываются по мере поступления - от самых дальних до ближних. Именно в таком порядке, как они идут в типизированном файле свойств объектов. Но для учета параметра глубины Z думал проводить сортировку списка объектов. То есть заносить их в отдельный список в нужном порядке. Вот теперь, в свете идеи модификаторов думаю - а не использовать ли класс-потомок модификатора для рендера... (в списке которого будут храниться в отсортированной последовательности видимые объекты, а невидимые не будут включены в этот список)...
В итоге, как я чувствую, мой движок становиться все более модульным, но зато, наверное, и более универсальным... Ну, поживем, увидим! :-)
Главное, что проект развивается, я получил новые идеи, которые реализую в движке. В определенный момент у меня был идейный ступор - до идеи отдельных объектов-модификаторов я не додумался, а работая с Менеджером Сцены обнаружил, что он все больше и больше разбухал и его код становился громоздким.

Правка: Вообщем, Менеджер Сцены, в том виде, в каком он сейчас существует - рудимент старой архитектуры, но жизнь меняется, в моем проекте появляются новые классы, и вся архитектура тоже должна (и будет - просто на все не доходят руки) изменяться в соответствии с новыми веяниями. (Короче - "Даду-даду! Даешь внедрешь!" :-) )

Подумал над архитектурой движка. Решил создать 2 новых класса вместо Менеджера Сцены:
TGlobalObjectMenager - будет хранить глобальный (общий) список объектов. Сможет загружать объекты из файла свойств объектов, добавлять объекты, а также сможет создавать новый объект - копию уже имеющегося объекта. Процедура загрузки текстур из файла свойств текстур будет принадлежать TextureMenager-у. Еще создам TSceneRender - класс-отрисовщик сцены. Этот класс будет иметь свой внутренний список ссылок на глобальный список объектов. Т.е. он будет по принципу действия похож на модификатор. Те объекты, которые нужно отрисовать - необходимо подключить к рендеру. Что будет делать Менеджер Сцены, лишенный всех этих обязанностей, пока не знаю.