Флейм
GameDev.ru / Флейм / Форум / Летопись багов (8 стр)

Летопись багов (8 стр)

Страницы: 17 8 9 1012 Следующая »
FlyOfFlyПостоялецwww3 мая 20182:02#105
MrShoor
>
> Далее смотрю на Methods. В OpenGL все функции начинаются с префикса gl. Нафига
> заводить Methods? Мне непонятно.
> Forward - вообще не понял. Какой в нем смысл то? Что еще есть в Methods,
> которое не относится к Forward, и может пересекаться?
>
> Почему Renderer лежит внутри Forward какого-то? Почему не внутри GreatVEngine2
> ?
Forward это же способ рендеринга, отсюда и Methods, тобишь методы рендеринга(Forward,Deferred,...). Правда, вот с Renderer и я не понял, зачем
MrShoorУчастникwww3 мая 20182:37#106
FlyOfFly
> Forward это же способ рендеринга, отсюда и Methods, тобишь методы
> рендеринга(Forward,Deferred,...)
Если так, то что тогда они делают в APIs::OpenGL? Какое отношение форвард рендеринг имеет вообще к графическому API?
FlyOfFlyПостоялецwww3 мая 20182:56#107
MrShoor
> Если так, то что тогда они делают в APIs::OpenGL? Какое отношение форвард
> рендеринг имеет вообще к графическому API?
>
Видимо, он слишком высокий уровень абстракций делает и выходит так. что он для каждого API пишет свой forward и deffered
Great V.Постоялецwww3 мая 201813:33#108
MrShoor
> APIs - В Graphics у тебя несколько графических апи. Но неймспейс под это дело
> выделять то зачем? Почему нельзя было в Graphics сразу расположить OpenGL,
> DirectX, whatever?
Если коротко - то я очень сцу что когда-то имена начнут перекрываться и потому сразу выношу в неймспейс-контейнер.
А еще выглядит как-то более упорядочено.

> Далее смотрю на Methods. В OpenGL все функции начинаются с префикса gl. Нафига
> заводить Methods?
Метод - это типа класс для "общего механизма", которым рисуется сцена. Типа forward или deferred rendering.

> Почему Renderer лежит внутри Forward какого-то? Почему не внутри GreatVEngine2
> ?
Это типа внутренний служебный класс, который рендерит конкретную сцену forward рендером.
Это, грубо говоря, уже реализация а не публичный интерфейс.

> Ну и наконец, можно вначале файла написать
Знаешь, никогда об этом не знал и не задумывался. Обязательно попробую, спасибо!

FlyOfFly
> Видимо, он слишком высокий уровень абстракций делает и выходит так. что он для
> каждого API пишет свой forward и deffered
Да, все верно.

Правка: 3 мая 2018 13:34

MrShoorУчастникwww3 мая 201820:37#109
Great V.
> Если коротко - то я очень сцу что когда-то имена начнут перекрываться и потому
> сразу выношу в неймспейс-контейнер.
Если внутри Methods у тебя не будет ни одной переменной, ни одного типа, а только другие неймспейсы типа Forward , Deferred и прочее, то там нечему будет перекрываться, а значит такой неймспейс не нужен.

> Метод - это типа класс для "общего механизма", которым рисуется сцена. Типа
> forward или deferred rendering.
Сомневаюсь, что у тебя получится сделать идентично. Но так же не понимаю, почему не взять для этих целей собственно класс? Зачем извращаться с неймспейсом то?

> Это типа внутренний служебный класс, который рендерит конкретную сцену forward
> рендером.
Извини, но выглядит это как говно. Когда какой-то класс из жопы мира типа GreatVEngine2::Graphics::APIs::OpenGL::Methods::Forward начинает лезть в GreatVEngine2::GameWorld это звиздец.

Я бы неймспейсы разложил примерно как-то так:

namespace GreatVEngine2 {
  namespace GameWorld { //типа игровые объекты, игровая логика там и все т.п. + данные для рендера
  }
  namespace GAPI { //сюда можно сложить интерфейсы для собственны классов типа VertexBuffer, IndexBuffer и прочее
    namespace OpenGL { //а тут реализация тех самых VertexBuffer IndexBuffer с помощью OpenGL
    }
    namespace DirectX { //а тут с помощью DX
    }
  }
  namespace Graphics { //тут типа рендер техники, всякие Forward, Deferred и прочее которые сделаны классами, а не неймспейсами. Graphics для рендера использует двух своих соседей, GameWorld и GAPI для вывода графики.
  }
}

Great V.Постоялецwww3 мая 201821:01#110
MrShoor
Не-не-не, ты не доганяешь...

У меня, например, есть неймспейсы:

GreatVEngine2::OpenGL
GreatVEngine2::Vulkan
И это неймспейсы самих GAPI. Там есть обертки над функциями, ООП, вспомогательные классы и т.д., но все эти объекты относятся только к этим библиотекам. Враперы, короче.
GreatVEngine2::OpenGL - это еще не графика, это только библиотека. Она нифига не знает про инфраструктуру движка.
И это важно. Если кто-то будет использовать именно это модуль (для математики, например), он не должен будет тянуть с собой всю графическую инфраструктуру.

А есть неймспес:
GreatVEngine2::Graphics
И уже он заправляет всей графикой. И вот в нем уже есть какие-то графический примитивы, типа:

GreatVEngine2::Graphics::Object
GreatVEngine2::Graphics::Material
GreatVEngine2::Graphics::Model
Но они абстрактные, ничего не знают о том, как, на чем и каким GAPI их будут рисовать.
И это важно. Если захочу - смогу хоть софтрендер навалять и рендерить одну и ту же сцену в двух окнах разными графическими движками.

Там же есть неймспейс в котором объявлены все "реализации" рендера:

GreatVEngine2::Graphics::APIs
В нем уже объявлены вложенные неймспейсы, которые описывают уже "графику", реализованную на каком-то API.
Например, неймспейс:
GreatVEngine2::Graphics::APIs::OpenGL
Описывает реализацию графики посредством библиотеки OpenGL.

Реализация графического движка, который может рисовать все эти GreatVEngine2::Graphics::Object выглядит где-то так:

GreatVEngine2::Graphics::APIs::OpenGL::Engine

Но сам графический движок может только "рисовать". Чтобы сказать "как" рисовать - есть класс:

GreatVEngine2::Graphics::APIs::OpenGL::Method
Производные от него классы реализуют разные модели рендера, которые и говорят "как" рисовать.
Например, forward рендером или deferred.

Чтобы все эти "методы рендера" не записывались с постфиксами, они были помещены в отдельный неймспейс Methods.
Класс:

GreatVEngine2::Graphics::APIs::OpenGL::Methods::Forward
Занимается рисованием сцены с использование forward рендера.
Для работы ему нужны всякие вспомогательные структуры, которые бы кешировали информацию и связывали логические объекты с буферами и шейдерами OpenGL.
Класс:
GreatVEngine2::Graphics::APIs::OpenGL::Methods::Forward::Renderer
Именно это и делает.

Правка: 3 мая 2018 21:05

MrShoorУчастникwww3 мая 201821:07#111
Great V.
> Не-не-не, ты не доганяешь...

> Именно это и делает.
Я понял, все очень грустно. Писанина ради писанины.

Great V.Постоялецwww3 мая 201821:14#112
MrShoor
> Писанина ради писанины.
Я с тобой не согласен.
Давай по порядку.
Что тебе больше всего не нравиться? Можешь сформулировать одним предложением?
Возможно тогда я смогу коротко и ясно тебе ответить.
MrShoorУчастникwww3 мая 201821:21#113
Great V.
Я тебе уже описал все раньше. Абстракции ради абстракций считаю не нужными.
Конкретно разделять вот это:
GreatVEngine2::OpenGL
и вот это:
GreatVEngine2::Graphics::APIs::OpenGL
не нужно.

Как и разделение:
GreatVEngine2::Graphics::APIs::OpenGL::Engine
GreatVEngine2::Graphics::APIs::OpenGL::Method

Вообще забей. Я определенно не смогу тебя переубедить. Поэтому предлагаю тебе продолжать делать как ты делаешь. Ну и когда-нибудь осознание придет.

Правка: 3 мая 2018 21:21

Great V.Постоялецwww3 мая 201821:29#114
MrShoor
> Конкретно разделять вот это и вот это не нужно.
Ну я же привел аргумент.
Если кому-то надо саму лишь либу OpenGL, зачем ему тянуть всю инфраструктуру работы с графическими объектами?

> Как и разделение
Есть такой патерн "мост". Вот Method для Engine - это "мост", который говорит как рисовать.
В чем здесь проблема? Это же, можно сказать, уже нюансы реализации, а не что-то публично доступное.

> Вообще забей. Я определенно не смогу тебя переубедить.
А ты постарайся. Может я не прав и ты направишь меня на путь истинный?
Я же не от балды задизайнил все именно так. Если это было ошибкой - я хочу узнать об этом как можно раньше. Желательно аргументированно.

Правка: 3 мая 2018 21:30

MrShoorУчастникwww3 мая 201821:42#115
Great V.
> Желательно аргументированно.
Любая абстракция, которую ты собираешься наворачивать - должна нести определенный функционал. Иначе это только замусоривание и усложнение кода.
Берем мой вариант:
  namespace GAPI { //сюда можно сложить интерфейсы для собственны классов типа VertexBuffer, IndexBuffer и прочее
    namespace OpenGL { //а тут реализация тех самых VertexBuffer IndexBuffer с помощью OpenGL
    }
    namespace DirectX { //а тут с помощью DX
    }
  }

Все интерфейсы объявлены внутри GAPI. Знаешь зачем? Чтобы тот, кто использует эту абстракцию вообще не знал ничего то том, какой именно это GAPI.

У тебя же ровно наоборот. Есть:
GreatVEngine2::OpenGL
и есть:
GreatVEngine2::Graphics::APIs::OpenGL
который знает, что это непосредственно OpenGL. Вопрос, нафига тогда вообще абстракция с GreatVEngine2::OpenGL ?

Great V.Постоялецwww3 мая 201821:48#116
MrShoor
> Вопрос, нафига тогда вообще абстракция с GreatVEngine2::OpenGL ?
Это не абстракция. Это врапер OpenGL, который умеет оперировать буферами, текстурами и шейдерами.
Но он ничего не знает о объектах, материалах, свете, тенях,  частицах, эффектах и т.д.
А вот GreatVEngine2::Graphics::APIs::OpenGL уже реализует рендер абстрактных графических примитивов средствами GreatVEngine2::OpenGL.
Ты считаешь что даже в таком случае необходимо объединить GreatVEngine2::OpenGL и GreatVEngine2::Graphics::APIs::OpenGL?
MrShoorУчастникwww3 мая 201821:57#117
Great V.
> Это не абстракция. Это врапер OpenGL, который умеет оперировать буферами,
> текстурами и шейдерами.
Ты перед тем как делать этот враппер ритуал проводил?
+ Показать

> Ты считаешь что даже в таком случае необходимо объединить GreatVEngine2::OpenGL
> и GreatVEngine2::Graphics::APIs::OpenGL?
Как я считаю, я уже написал тебе.
Я считаю что нужно писать меньше, а функционала чтобы было больше. Идею писать Forward на каждом GAPI (а их я так понял у тебя будет минимум 3) я бы сразу выкинул.

Правка: 3 мая 2018 21:57

Great V.Постоялецwww3 мая 201822:05#118
MrShoor
> Ты перед тем как делать этот враппер ритуал проводил?
Ну да.
Это врапер превращает glGetError в исключения, а glGenBuffer/glDeleteBuffer в RAII.
Этого недостаточно?

> Идею писать Forward на каждом GAPI (а их я так понял у тебя будет минимум 3) я
> бы сразу выкинул.
Это уже второй пункт.

Как я понял, против первого ты уже не настолько радикально настроен : )

Роман ШуваловУчастникwww3 мая 201822:16#119
MrShoor
Я ничему не научился:
pool->chunk_index_numpool[--pool->chunk_index_numpool_pos] = chunk_index;

(Ошибки нет, просто теперь ++ и -- у меня в ходу, так что ждите новых историй в треде.)

Страницы: 17 8 9 1012 Следующая »

/ Форум / Флейм / Программирование

2001—2018 © GameDev.ru — Разработка игр