Войти
ФлеймФорумПроЭкты

BerylEngine: 0.09 [95 из 365] (22 стр)

Страницы: 121 22 23 2453 Следующая »
#315
7:02, 9 апр. 2018

war_zes
> И если идти дальше, то смотришь какой-нибудь bgfx (который типа на си-стайл) и
> сравниваешь его с любым граф движком - и последний часто выглядит хуже за своей
> тонной бесполезного кода.

Ты видишь граф движок только как рендер, а в самом движке есть ещё до кучу всего - 100-500 раз тебе поясняли


#316
7:09, 9 апр. 2018

Еще немного подумав понял что мне не нужно многопоточное создание рендер ресурсов. Я все равно их создаю в основном потоке, загружая в другом потоке только предварительную информацию.
Короче - многопоточная загрузка будет вынесена в более высокий уровень - на уровень моделей и материалов.

Так что дочищу код, залью и продолжу... всеже надо начинать проект

#317
7:09, 9 апр. 2018

innuendo
> Ты видишь граф движок только как рендер, а в самом движке есть ещё до кучу
> всего - 100-500 раз тебе поясняли
рендер движка часто достаточно для создания инди игр.

#318
8:02, 9 апр. 2018

StepEver
> потом за пять минут долететь.
это "потом" может никогда и не наступить, а время потратишь.
Писать код с закладом на будуще = одна из причин, почему этот код никогда не будет написан
Писать код с закладом на будущее, без опыта ранних проектов - еще более высокий шанс убить проект. Нельзя подготовиться к тому, с чем никогда не сталкивался.

Над большими проектами работают команды, с лидами имеющими многолетний опыт.
Я один, и опыта у меня нет


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

#319
(Правка: 8:18) 8:15, 9 апр. 2018

war_zes
> Когда один движок из каких-нибудь 60к строк кода, и на нем делают игры, а
> второй движок из миллионов строк кода, и на нем нельзя сделать игру - у кого из
> них правильная архитектура? и я не об говнокодерах:
> первый пример - движок... ну например на котором делали Amnesia/SOMA.
Лол. У тебя 10к строк кода и движка за оберткой надо OpenGL до сих пор не видно. Так что там о количестве строк?
> Еще немного подумав понял что мне не нужно многопоточное создание рендер
> ресурсов. Я все равно их создаю в основном потоке, загружая в другом потоке
> только предварительную информацию.
> Короче - многопоточная загрузка будет вынесена в более высокий уровень - на
> уровень моделей и материалов.
Лол 2. Столько времени просрать на загрузку в другом потоке, и выпилить. Вот так и пишут огромные движки. Хочу-хочу-хочу. А не, нах не надо, в реальном проекте. Трешь за "не писать лишний код", а сам в итоге только его и пишешь.

#320
(Правка: 8:35) 8:34, 9 апр. 2018

StepEver
> А шаблоны и интерфейсы ты тоже отвергаешь
У него обертка над OpenGL частично на шаблонах. С чего я дико лоллирую. Там где надо передавать указатель он зачем-то оборачивает в T&. Потом будет переделывать, когда будет заливать анонимную структуру из файла.

#321
8:46, 9 апр. 2018

StepEver
Это была загрузка данных через glBufferData(&T, sizeof(T)). Но почему-то я теперь не могу найти этот код. То ли я упоролся, то ли он что-то откатил или переделал.

#322
8:48, 9 апр. 2018

Таки да, сорян. Я упоролся. My bad.

template <typename T>
void SetData(const T &value)
{
    Buffer::SetData(static_cast<const void*>(&value), sizeof(value));
}

#323
8:50, 9 апр. 2018

war_zes
> Писать код с закладом на будуще = одна из причин, почему этот код никогда не
> будет написан
Утащил в перлы)

#324
8:55, 9 апр. 2018

war_zes
немного гляну чего написано.
вот навскидку

//-----------------------------------------------------------------------------
void IndexBuffer::Bind()
{
  glBindBuffer(m_type, m_bufferId);
}
//-----------------------------------------------------------------------------
void IndirectBuffer::Bind()
{
  glBindBuffer(m_type, m_bufferId);
}
void VertexBuffer::Bind()
{
  glBindBuffer(m_type, m_bufferId);
}
зачем столько копипаста? Bind() - это в базовый класс, еще пару assert на входные параметры не помешает. Меньше кода больше дела.
[code=cpp]
Buffer::~Buffer()
{
assert(glIsBuffer(m_bufferId) && "Invalid Buffer"); // хотя у тебя GL_ARB_debug_output ну не помешает.
}
Гляну еще позже.
#325
9:06, 9 апр. 2018

StepEver
nullptr как параметр в glBufferData вполне себе валиден. Последний код это из константного буфера. Скорее всего подразумевалось, что он планируется туда грузить структуру (одну). Глупо, конечно, но вариант работоспособный.

#326
(Правка: 9:12) 9:12, 9 апр. 2018

Andrey
А про enum (struct) SomeEnum : GLenum { zero = GL_ZERO, ...}. war_zes свичует.

#327
9:14, 9 апр. 2018

Dampire
Расскажите про ваш опыт?
10 лет писал прослойку между 3dmax.exe и glDrawElements.

#328
(Правка: 9:18) 9:18, 9 апр. 2018

lookid
Я написал законченную игру на своем движке. *много-много воды* и таким образом *еще чуть-чуть воды* никоим образом нельзя!!! *последняя капелька* так я и стал экспертом в области написания движков. Вопросы?

#329
9:22, 9 апр. 2018

Andrey
> Bind() - это в базовый класс, еще пару assert на входные параметры не помешает.
> Меньше кода больше дела.
ровно до тех пока, не не приходит константый буфер, с совершенно другим Bind

void ConstantBuffer::Bind(uint8_t slotIndex)
{
  glBindBufferBase(GL_UNIFORM_BUFFER, slotIndex, m_bufferId);
}
У которого добавляется входящий аргумент, и другая реализация тела.

Из-за чего получается коряво, когда Bind общий, то в констант буфере он болтается непонятно зачем.
Так что да, это один из случаев - когда я сделал копипаст, чтобы этого лишнего Bind не было в константаном буфере (можно было бы изворотиться приватностью базового Bind и перекрытием через полиморфизм - но все это фигня)

Страницы: 121 22 23 2453 Следующая »
ФлеймФорумПроЭкты