Комментарии 26
glBegin(GL_QUADS);
glVertex2f(-1.0f, 1.0f);
glVertex2f(1.0f, 1.0f);
glVertex2f(1.0f, -1.0f);
glVertex2f(-1.0f, -1.0f);
glEnd();
Ой! Сожгите, пожалуйста, вашу методичку, учебник, что у вас там. OpenGL 1.0, созданный в 1992 году, к данному моменту сильно устарел. Его поддержка сейчас имеется на десктопах, и то в режиме эмуляции. В современных драйверах видеокарт это приводит к проблемам с производительностью — на старых драйверах программы работают лучше, чем на новых.
На мобильных устройствах такого режима нет совсем, все только через шейдеры.
Так что учите шейдеры. Иначе ваши знания, приобретенные в процессе работы над этим проектом, окажутся на практике бесполезными в большом проценте случаев. Исключением будет разве что перенос дремучего легаси, которое еще надо поискать.
Судя по коду, уже используются какие-то стандартные шейдеры.
Впрочем, компьютерной графики на первом курсе не было вообще, так что сжигать пока нечего.
//https://github.com/Glebanister/ample/blob/76f20b27e15366f38dd351ec34506d323d002091/core/src/Graphics/Shaders/Shader.cpp
sstr << shaderStream.rdbuf();
if (!sstr.good() || !shaderStream.good())
{
throw exception::Exception(exception::exId::FILE_READ,
exception::exType::CASUAL);
}То есть, тут ошибка stream переводится в исключение. Но зачем — stream сам умеет швырять исключения, нужно только настроить.
exception::OpenGLException::handle();
Вот пример одной из начальных версий
www.youtube.com/watch?v=hl0eIBFhKKk
К сожалению разработка движка сжирает просто огромное количество времени, настолько огромное, что я хотел прикрутить к двигу AngelScript и на нём оформлять логику по типу плагин системы, так как AS позволяет в реалтайме менять логику. Писать двиг это вливать время в пустоту, но очень интересно) Движков, кстати очень много валяется на гите, можно изучать
Но если вы планируете на этом движке писать мало-мальски сложную игру, советую отказаться от концепции объекта с виртуальными методами и смотреть в сторону паттерна entity component system. Например, библиотеки EnTT. Они позволяют эффективно использовать кэш CPU и избежать накладных расходов от виртуальных методов а-ля update.
Также, я бы посоветовал всё же заморочиться и заинтегрировать окно движка в Qt окно для целей редактирования. Сейчас работаю в компании, где огроменный игровой редактор написан на imgui и также интегрирован в игру, и подправлять что-то в нём это боль. Ни шорткатов тебе нормальных, ни окошек, не редактор, а какой-то среднеазиатский рынок, уж простите.
void onActive(): onActive() for sb in subBehaviors: sb.onActive()
Статья огонь, только что это за странный питоний синтаксис? У вас там какой-то препроцессор все это дело обрабатывает?
А есть код подсмотреть как выглядят ваши стейтмашинные блюпринты?
Я имел ввиду вот те штуки которые отображаются в редакторе. Хотел подглядеть как вы линии между виджетами дорисовываете. Оно оказывается через imnodes скрафчено
Вот например VertexArray.cpp
И даже самые простые шейдеры: Shaders
result[i * 3 + 0] = vector[i].x;
result[i * 3 + 1] = vector[i].y;
result[i * 3 + 2] = vector[i].z;Это стандартный код, побуждающий сделать стандартную ошибку — эффект последней строки.
Даже Кармак на этом ловился:
if (fabs(dir[0]) > test->radius ||
fabs(dir[1]) > test->radius ||
fabs(dir[1]) > test->radius)Решение — пользоваться массивами и писать циклы.
{{x1, y1, z1}, {x2, y2, z2}} в массив чисел, который можно затем передать в OpenGL {x1, y1, z1, x2, y2, z2}. Во всем проекте не очень удобно оперировать вершинами без структуры Vector3d, содержащей трехмерные координаты, и так могло бы потенциально образоваться гораздо больше ошибок, чем если в одном месте пожертвовать красотой кода, написав такую развертку.
По набору фичей для первого курса неплохой результат. Правда в реальной разработке совсем другие проблемы — миддлвара затачивается под реальные задачи использующих её приложений, и это сильно меняет процесс постановки и решения задач.
Как мне кажется, сейчас вы просто смотрите на чужие движки и делаете себе такое же. Но в коммерческой разработке такой подход будет только мешать. Я думаю, что движок эффективнее делать под конкретную игру — тогда вы получите более релевантный опыт. Так-то на рынке много программистов, умеющих реализовать сферический движок в вакууме. Но обычно эти решения не позволяют получить прибыли при использовании на реальных проектах, призванных приносить деньги. А вот программистов, оптимизирующих движки под нужды целевого проекта, — мало, они более эффективны и высоко ценятся работодателями.
Да, на первом курсе задача у нас в этом году примерно так и ставится: сделать что-нибудь работающее, в ~первый раз потренироваться в командной разработке и проектах на C++ длиннее нескольких недель. Не требуется научной новизны, прорывов или даже детального изучения предметной области или разумного выбора технологий.
По верхам прошлись, грабли пособирали, что-то слепили и поняли, как не надо делать — уже здорово.
На втором курсе и дальше требования, конечно, повышаются. Например, на третьем курсе можно индивидуально разработать и защитить что-нибудь такое. Уже надо детально рассказать, чем плохи существующие решения, и предложить что-то своё. Не дай бог прямой аналог будет на первой странице выдачи гугла. При этом, так как работа скорее академическая, доводить до хорошего продукта и поддерживать-развивать времени обычно нет, но это тоже понимают и студент, и комиссия.
Написать игровой движок на первом курсе: легко! (ну почти)