Графическая система движка (комментарии)

Графическая система движка (комментарии)

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

всегда когда вижу инициализацию приложения вроде:

class CApplication: public CBaseApplication
{
protected:
HWND hWnd;

public:
int InitApplication ( void );
};

иду блевать. На кой черт вам этот ООП сдался.

Larik
а как бы ты написал меж платформенный движок.
скажу честно сам ооп не люблю ,но всё же...

VanZ
А какая связь между ОС и ООП ?

Larik
>А какая связь между ОС и ООП ?
никакой
щас везде эти классы ,наверное не просто так..
если ООП не юзать ,то зачем он нужен(я в поисках ответа).

вот решил у тебя спросить ,как без ООП делают.

VanZ
> вот решил у тебя спросить ,как без ООП делают.
никак :)

все уже давно перешли на ООП, потому что это белая и пушистая няка :)

Larik
Нравится мне ООП, на С++ его уже хз сколько лет использую, удобно.
Так же и в ПХП и в питоне, лично как по мне, очень удобная парадигма программирования.
Но и функциональный подход так же хорош в некоторых случаях.

Кросплатформенный движок можно сделать и с функциональным подходом, например использовать переопределённые наборы функций для каждой системы. Ну и при той или иной сборке просто подрубать нужные чеерз typedef с макросами.

у меня несколько вопросов по архитектуре...

есть функция void Draw(); - рисование графического объекта
есть классы pTSpriteViewer  и pTBaseVertexData которые хранятся в спрайте
у меня вопрос, эти классы используются вне функции Draw? может стоило их передавать в функцию по ссылке?
или может "книга не должна читать сама себя"? поэтому вместо функции Draw сделать 2 функции которые вернут эти 2 класса, тому кто попросит и пусть он сам решает как это рисовать?

Larik
+100500. кроме кучи неудобств этот класс ничего не несет...

Pushkoff
Это как раз и есть ссылки :)
Но pTSpriteViewer у каждого спрайта создаётся свой в зависимости от типа рендера и(в будущем) системы.
А вот с pTBaseVertexData несколько сложнее, он может быть как в личном пользовании спрайта, так и внешним. VertexPool как раз задаётся по этому указателю.

Вообще конечно можно сделать менеджер рисования графических объектов, ничего сложного там нет. Но вот как то "атомарное" поведение объектов мне нравится больше, больше возможностей.

Но вообще вот пример из реального приложения, как использовался Draw
В приложении основная сцена и сцена отображения загрузки данных из и-нета.
Основная сцена организована с полным использованием всех менеджеров, очереди отрисовки. Ток пул вершин не использовался.
А вот сценка загрузки - всего два спрайта, один анимация, второй просто чёрный фон. Ну и когда происходило получение данных и загрузка ресурсов, то просто вместо всей сцены только эти два спрайта и рисовалось. А в структуре с менегером надо было бы ещё и его добавить.
Конечно это просто пример реализации и вариант с отдельным менеджером отрисовки ничем не хуже.

Ну а как по мне, класс-приложение удобен в использовании. На вкус и цвет...
Тем более ни кто не мешает просто сделать классический бесконечный цикл для работы приложения.

Не много дополню что бы больше понятно:)
TSpriteViewer - это сам класс.
pTSpriteViewer - это указатель на класс.
В движеке принято такое обозначение, если в переди стоит маленькое "p" это указатель на класс. Об этом есть упоминания в статье.

Что касается использования у вас получается как минимум 3 варианта:
1. Использовать сами спрайт и функцию Draw() графического обьекта и самому организовывать очередь от рисовки и использовать один большой цикл.
2. Использовать менеджер графических объектов.
3. Использовать очередь от рисовки и регистрировать в ней обьекты на прямую.
Все на ваш вкус. Как кто хочет.

мне сложно понять зачем нам 3 метода рисования когда вполне достаточно 1...
просто представьте ситуацию что игра на вашем движке начнет занимать кучу файлов в которых будут использоваться разные методы отрисовки... разобраться в коде такой игры будет тем сложнее, чем больше ненужных возможностей будет использовано...

Monax-At
> А вот сценка загрузки - всего два спрайта, один анимация, второй просто чёрный фон. Ну и когда происходило получение данных и загрузка ресурсов, то просто вместо всей сцены только эти два спрайта и рисовалось. А в структуре с менегером надо было бы ещё и его добавить.
> Конечно это просто пример реализации и вариант с отдельным менеджером отрисовки ничем не хуже.
вот у меня опять вопрос, где будет храниться список объектов которые необходимо выводить? мне кажется этот класс или место в любом случае будет менеджером или будет исполнять обязанности менеджера (в зависимости от кривизны архитектуры).

Pushkoff
Если в игре  или в сложном проекте,использовать все три вида организации графических обьектов, то за такое программирование надо отбивать руки на коню, в такой программе действительно будет сложно разобраться и веной будет не движок и не его архитектура, а прокладка между клавиатурой и стулом.
Ну вернемся к нашем баранчикам:) Есть три метода огранизации как я и говорил на цвет и на вкус:) Если вам надо на крапать что-то простое, то нафиг вам менеджеры, очереди, особенно если что-то экспериментальное(Сами и дергаете Draw() у обьекта когда вам надо), а вот если что действительно сложное тогда организовывайте, у вас есть для этого все не обходимое.

Pushkoff
>вот у меня опять вопрос, где будет храниться список объектов которые необходимо выводить? мне кажется этот класс или место в любом случае будет менеджером или будет исполнять обязанности менеджера (в >зависимости от кривизны архитектуры).
Да, для этого предусмотрен менеджеры: TSpriteListManager, TSpriteBankListManager
TSpriteListManager - отвечает за спрайты, ну а второй отвечает за спрайт банки. Как показывает практика спрайт банки очень полезная штука при правильном использовании хотя все при правильном использовании по полезная штука.

Larik
> всегда когда вижу инициализацию приложения вроде:
> class CApplication: public CBaseApplication
> {
> protected:
> HWND hWnd;
> public:
> int InitApplication ( void );
> };
> иду блевать. На кой черт вам этот ООП сдался.

жжёшь :)
напалмом

MaximusPrime
> то за такое программирование надо отбивать руки на коню
можешь уже растить отрывалку рук, так как то что не запрещено - то позволено... поверь когда в проэкте будет больше 100 файлов, архитектору будет хватать времени только на код ревью... при чем у вас кроме ревью появятся еще разборки а что на самом деле быстрее и производительнее...
для того чтоб избежать, в движке нужно выделить 1 максимально быстрый и универсальный метод, а для всяких мелких нужд написать утилиты...

Larik
> class CApplication: public CBaseApplication
> {
> protected:
> HWND hWnd;
> public:
> int InitApplication ( void );
> };
> иду блевать. На кой черт вам этот ООП сдался.
этот класс очень удобен, НО, он предусматривает возможность инициализации приложения только через него...
это полезно для игрового движка, который является основой, но очень мешает графическому, потому что мешает совместному использованию этого движка с другими системами которые могут требовать инициализацию граф движка в совсем другом виде, или даже уже использовать базовый класс application
по возможности этот класс нужно перенести в категорию "расширенное", и писать код так чтобы графическая чать не обязывала начинать приложение именно с этого класса
но повторю что этот класс очень полезен для больших фреймворков которые являются оболочкой всего приложения