Создание игр на opengl. Игровые движки на Go

Продолжается цикл статей, посвященных работе с библиотекой на нашем сайте, и, наконец, пришло время подключить третье измерение в наших экспериментах) Сегодня мы создадим в пространстве куб, а также добавим функцию вращения фигуры вокруг осей x и y . Как всегда разберем все по шагам, а в конце статьи я выложу полный проект с реализованным примером.

За основу давайте возьмем проект из предыдущего урока (), как и тогда, для построения изображения мы сегодня будем использовать массивы вершин, индексов и цветов . Давайте разберем нашу задачу…

Что из себя представляет куб? Ответ прост – 6 граней (квадратов) и 8 вершин 😉 Именно так мы и будем строить фигуру – построим по отдельности 6 его граней, а эта задача для нас уже не представляет никакой сложности.

Но прежде, чем приступать к рисованию, добавим в функцию initializeGL() следующее:

glShadeModel(GL_FLAT) ; glEnable(GL_CULL_FACE) ;

Помните на прошлом уроке, когда мы задавали разные цвета вершин у одной фигуры, то получали красивые переходы между цветами. Так вот сегодня нам это не нужно, грани будут иметь однородный цвет и именно для включения этого режима (а точнее для отключения режима сглаживания цветов) мы вызываем первую из этих функций. Цвет грани у нас теперь будет определяться цветом последней(!) нарисованной вершины квадрата.

Вторая функция устанавливает режим, когда строятся только внешние поверхности фигур. И вот тут есть один важный момент. Для корректного отображения объекта вершины в массиве вершин должны задаваться против(!) часовой стрелки.

Собственно, с приготовлениями на этом заканчиваем, начинаем отрисовку. Нам понадобятся три массива:

GLfloat cubeVertexArray[ 8 ] [ 3 ] ; GLfloat cubeColorArray[ 8 ] [ 3 ] ; GLubyte cubeIndexArray[ 6 ] [ 4 ] ;

С размерами массивов мы разобрались на прошлом уроке, не буду повторяться, поэтому сразу же переходим к заполнению их данными. Кстати ребро нашего куба будет равно единице, в соответствии с этим задаем координаты вершин в трехмерном пространстве:

cubeVertexArray[ 0 ] [ 0 ] = 0.0 ; cubeVertexArray[ 0 ] [ 1 ] = 0.0 ; cubeVertexArray[ 0 ] [ 2 ] = 1.0 ; cubeVertexArray[ 1 ] [ 0 ] = 0.0 ; cubeVertexArray[ 1 ] [ 1 ] = 1.0 ; cubeVertexArray[ 1 ] [ 2 ] = 1.0 ; cubeVertexArray[ 2 ] [ 0 ] = 1.0 ; cubeVertexArray[ 2 ] [ 1 ] = 1.0 ; cubeVertexArray[ 2 ] [ 2 ] = 1.0 ; cubeVertexArray[ 3 ] [ 0 ] = 1.0 ; cubeVertexArray[ 3 ] [ 1 ] = 0.0 ; cubeVertexArray[ 3 ] [ 2 ] = 1.0 ; cubeVertexArray[ 4 ] [ 0 ] = 0.0 ; cubeVertexArray[ 4 ] [ 1 ] = 0.0 ; cubeVertexArray[ 4 ] [ 2 ] = 0.0 ; cubeVertexArray[ 5 ] [ 0 ] = 0.0 ; cubeVertexArray[ 5 ] [ 1 ] = 1.0 ; cubeVertexArray[ 5 ] [ 2 ] = 0.0 ; cubeVertexArray[ 6 ] [ 0 ] = 1.0 ; cubeVertexArray[ 6 ] [ 1 ] = 1.0 ; cubeVertexArray[ 6 ] [ 2 ] = 0.0 ; cubeVertexArray[ 7 ] [ 0 ] = 1.0 ; cubeVertexArray[ 7 ] [ 1 ] = 0.0 ; cubeVertexArray[ 7 ] [ 2 ] = 0.0 ; cubeColorArray[ 0 ] [ 0 ] = 0.0 ; cubeColorArray[ 0 ] [ 1 ] = 0.0 ; cubeColorArray[ 0 ] [ 2 ] = 1.0 ; cubeColorArray[ 1 ] [ 0 ] = 0.6 ; cubeColorArray[ 1 ] [ 1 ] = 0.98 ; cubeColorArray[ 1 ] [ 2 ] = 0.6 ; cubeColorArray[ 2 ] [ 0 ] = 1.0 ; cubeColorArray[ 2 ] [ 1 ] = 0.84 ; cubeColorArray[ 2 ] [ 2 ] = 0.8 ; cubeColorArray[ 3 ] [ 0 ] = 0.8 ; cubeColorArray[ 3 ] [ 1 ] = 0.36 ; cubeColorArray[ 3 ] [ 2 ] = 0.36 ; cubeColorArray[ 4 ] [ 0 ] = 1.0 ; cubeColorArray[ 4 ] [ 1 ] = 0.27 ; cubeColorArray[ 4 ] [ 2 ] = 0.0 ; cubeColorArray[ 5 ] [ 0 ] = 0.82 ; cubeColorArray[ 5 ] [ 1 ] = 0.13 ; cubeColorArray[ 5 ] [ 2 ] = 0.56 ; cubeColorArray[ 6 ] [ 0 ] = 0.54 ; cubeColorArray[ 6 ] [ 1 ] = 0.17 ; cubeColorArray[ 6 ] [ 2 ] = 0.89 ; cubeColorArray[ 7 ] [ 0 ] = 0.0 ; cubeColorArray[ 7 ] [ 1 ] = 1.0 ; cubeColorArray[ 7 ] [ 2 ] = 1.0 ;

Мы задали координаты и цвета вершин куба. Давайте для наглядности посмотрим на рисунок:

Номера вершин на рисунке полностью соответствуют тому, как мы их задали в нашей программе. Теперь, глядя на картинку можно с легкостью пройтись по всем 6 граням куба и заполнить массив индексов. Давайте смотреть:

• Грань 1 – вершины 0, 3, 2, 1
• Грань 2 – вершины 0, 1, 5, 4
• Грань 3 – вершины 7, 4, 5, 6
• Грань 4 – вершины 3, 7, 6, 2
• Грань 5 – вершины 1, 2, 6, 5
• Грань 6 – вершины 0, 4, 7, 3

Теперь тоже самое делаем в программе =)

cubeIndexArray[ 0 ] [ 0 ] = 0 ; cubeIndexArray[ 0 ] [ 1 ] = 3 ; cubeIndexArray[ 0 ] [ 2 ] = 2 ; cubeIndexArray[ 0 ] [ 3 ] = 1 ; cubeIndexArray[ 1 ] [ 0 ] = 0 ; cubeIndexArray[ 1 ] [ 1 ] = 1 ; cubeIndexArray[ 1 ] [ 2 ] = 5 ; cubeIndexArray[ 1 ] [ 3 ] = 4 ; cubeIndexArray[ 2 ] [ 0 ] = 7 ; cubeIndexArray[ 2 ] [ 1 ] = 4 ; cubeIndexArray[ 2 ] [ 2 ] = 5 ; cubeIndexArray[ 2 ] [ 3 ] = 6 ; cubeIndexArray[ 3 ] [ 0 ] = 3 ; cubeIndexArray[ 3 ] [ 1 ] = 7 ; cubeIndexArray[ 3 ] [ 2 ] = 6 ; cubeIndexArray[ 3 ] [ 3 ] = 2 ; cubeIndexArray[ 4 ] [ 0 ] = 1 ; cubeIndexArray[ 4 ] [ 1 ] = 2 ; cubeIndexArray[ 4 ] [ 2 ] = 6 ; cubeIndexArray[ 4 ] [ 3 ] = 5 ; cubeIndexArray[ 5 ] [ 0 ] = 0 ; cubeIndexArray[ 5 ] [ 1 ] = 4 ; cubeIndexArray[ 5 ] [ 2 ] = 7 ; cubeIndexArray[ 5 ] [ 3 ] = 3 ;

Теперь осталось только вызвать функцию рисования:

glVertexPointer(3 , GL_FLOAT, 0 , cubeVertexArray) ; glColorPointer(3 , GL_FLOAT, 0 , cubeColorArray) ; glDrawElements(GL_QUADS, 24 , GL_UNSIGNED_BYTE, cubeIndexArray) ;

Запускаем программу и видим наш куб!

Правда на данный момент он больше похож на квадрат 😉 Все потому что мы смотрим на куб со стороны оси z и видим его проекцию на плоскость X0Y . Для того, чтобы все-таки увидеть, что это действительно куб, давайте добавим возможность вращать фигуру при удержании кнопки мыши и перемещении ее указателя.

Сделаем так – при перемещении указателя мыши от левого края до правого будем поворачивать куб на 180 градусов. Осталось вычислить, на сколько градусов нужно повернуть фигуру при произвольном перемещении курсора. С этим все просто, получаем формулу:

yAngle = 180 * d / w;

Здесь d – это расстояние, на которое мы переместили курсор, w – ширина нашего окна. Обратите внимание, что при движении мыши вдоль оси x поворот будет осуществляться вокруг оси y , и наоборот, перемещение вдоль y – поворот вокруг x .

Итак, сейчас нам нужно получить в программе данные о перемещениях мыши. Для этого переопределим методы:

void MainScene:: mousePressEvent (QMouseEvent * event) { pressPosition = event-> pos() ; } void MainScene:: mouseMoveEvent (QMouseEvent * event) { xAxisRotation += (180 * ((GLfloat) event-> y() - (GLfloat) pressPosition.y () ) ) / (currentHeight) ; yAxisRotation += (180 * ((GLfloat) event-> x() - (GLfloat) pressPosition.x () ) ) / (currentWidth) ; pressPosition = event-> pos() ; updateGL() ; }

При нажатии кнопки мыши (mousePressEvent() ) сохраняем в переменную pressPosition текущие координаты курсора. При перемещениях указателя производим расчет углов поворота, на которые необходимо развернуть куб, а затем вызываем функцию updateGL() для перерисовки сцены в соответствии с полученными данными. Не забываем объявить все используемые методы и переменные в файле MainScene.h.

Функцию updateGL() то мы вызвали, но само собой ничего, естественно, не повернется)

Для поворота фигуры предлагает нам следующую функцию:

То фигура повернется вокруг оси x на 45 градусов.

С этим все понятно, осталось только добавить вызов этой функций к нам в программу, а точнее в функцию paintGL() :

Как видите, все оказалось довольно-таки просто)

Теперь нам предстоит собрать проект и проверить результат:

На этом заканчиваем сегодняшнюю статью! А уже скоро, а именно в следующем уроке, мы разберемся с текстурами в – создадим собственные текстуры и нанесем их на 3D объекты, так что до скорого, не пропустите новую статью 😉

• Перевод

Перед тем как мы начнём, скажу: я знаю об OpenGL гораздо больше чем о Direct3D. Я в жизни не написал ни одной строки кода для D3D, и я писал руководства по OpenGL. Так что то что я тут расскажу, не вопрос предвзятости. Теперь это просто история.

Зарождение конфликта

Однажды, в начале 90-х, Microsoft огляделась вокруг. Они увидели замечательные Super Nintendo и Sega Genesis, на которых было много отличных игр. И они увидели DOS. Разработчики писали для DOS так же как для консолей: прямо на железе. Но, в отличии от консолей, где разработчик точно знал каким железом располагает пользователь, разработчики для DOS вынуждены были писать в расчёте на множество различных конфигураций оборудования. А это гораздо сложнее, чем кажется на первый взгляд.

У Microsoft в то время была ещё большая проблема: Windows. Windows хотела единолично распоряжаться оборудованием, в отличие от DOS, позволявшей разработчику делать всё что ему заблагорассудится. Владение оборудованием было обязательно для того чтобы упорядочить взаимодействие между приложениями. Взаимодействие-то и не нравилось разработчикам игр, потому что забирало ценные ресурсы, которые они могли использовать для своих замечательных игр.

Чтобы привлечь разработчиков игр в Windows, Microsoft нужен был единый API который был бы низкоуровневым, работал в Windows и при этом не страдал от тормозов и, самое главное, абстрагировал бы от разработчика оборудование . Единый API для графики, звука и пользовательского ввода.

И так родился DirectX.

3D ускорители появились на свет несколько месяцев спустя. И перед Microsoft встало сразу несколько проблем. Видите ли, DirectDraw, графический компонент DirectX, работал только с 2D графикой: выделением графической памяти и побитовым копированием между разными выделенными секциями памяти.

И Microsoft купили некий промежуточный драйвер и сделали из него Direct3D версии 3. Его ругали все и повсюду . И не просто так; одного взгляда на код было достаточно чтобы отшатнуться в ужасе.

Старый Джон Кармак из Id Software взглянул на этот мусор, сказал: «К чёрту!», и решил писать под другой API - OpenGL.

Другая часть этого клубка проблем состояла в том что Microsoft были очень заняты совместной работой с SGI над реализацией OpenGL для Windows. Идея была проста - привлечь разработчиков типичных рабочих GL-приложений: систем автоматического проектирования, моделирования, всего такого. Игры были последним, о чём тогда думали в Microsoft. Это всё предназначалось для Windows NT, но Microsoft решили добавить эту реализацию и в Win95.

Чтобы привлечь внимание разработчиков профессионального софта к Windows, Microsoft попробовали подкупить их доступом к новым функциям ускорителей трехмерной графики. Microsoft сделали протокол Installable Client Driver: производитель графического ускорителя мог перегрузить программную реализацию OpenGL аппаратной. Код просто автоматически использовал аппаратную реализацию если она была доступна.

Восход OpenGL

Итак, расклад сил был определён: Direct3D против OpenGL. Это действительно интересная история, учитывая насколько ужасен был D3D v3.

Комитет Архитектурных Решений OpenGL («Architectural Review Board», ARB) был организацией, ответственной за поддержку стандарта OpenGL. Они выпустили много расширений, следили за репозиторием расширений и создавали новые версии API. В Комитет входили многие влиятельные игроки графической индустрии и разработчики ОС. Apple и Microsoft в своё время тоже входили в этот комитет.

Потом появился 3Dfx с Voodoo2. Это было первое устройство, способное выполнять мультитекстурирование, чего OpenGL делать раньше не мог. Хотя 3Dfx совершенно не вписывался в стандарт OpenGL, NVIDIA, разработчик последующих графических чипов с мультитекстурированием (TNT1), положили глаз на эту реализацию. ARB пришлось выпустить расширение: GL_ARB_multitexture, которое давало доступ к мультитекстурированию.

В это же время вышел Direct3D v5. Теперь D3D стал настоящим API , а не странным куском кошачьей рвоты. Проблема? Отсутствие мультитекстурирования.

По большому счёту, это было не так важно как должно было быть, потому что люди особо не использовали мультитекстурирование. По крайней мере напрямую. Мультитекстурирование сильно ухудшало быстродействие, и во многих случаях просто не было смысла использовать его вместо multi-passing. И, естественно, разработчики игр старались убедиться что их игры заработают на старом железе, в котором мультитекстурирования не было, и многие игры его просто не использовали.

D3D это сошло с рук.

Прошло какое то время и NVIDIA выпустили GeForce 256 (не GeForce GT-250; самый первый GeForce), по большому счёту прекратив гонку вооружений в графических ускорителях на следующие два года. Основная продающая фишка - возможность делать вертексные преобразования и освещение (T&L) аппаратно. Но это не всё: NVIDIA настолько полюбили OpenGL, что их движок T&L по сути и был OpenGL. Причём буквально: насколько я понимаю, некоторые регистры действительно напрямую принимали объекты OpenGL в качестве значений.

Выходит Direct3D v6. Наконец появилось мультитекстурирование, но… нет аппаратного T&L. У OpenGL всегда был конвеер T&L, даже до того как вышел 256 он был реализован программно. Так что для NVIDIA было не очень сложно преобразовать программную реализацию в аппаратную. В D3D аппаратный T&L появился только к седьмой версии.

Рассвет шейдеров, сумерки OpenGL

Потом вышел GeForce 3 и одновременно произошло много вещей.

Microsoft решили что теперь-то они уж точно не опоздают к празднику. И вместо того чтобы смотреть что делают NVIDIA и копировать это постфактум они пришли к NVIDIA и поговорили. Потом они полюбили друг друга и от этого союза появилась маленькая игровая приставка.

Потом был болезненный развод. Но это совсем другая история.

Для PC это значило что GeForce 3 вышел одновременно с D3D v8. И несложно увидеть насколько GeForce 3 повлиял на шейдеры в восьмерке. Пиксельные шейдеры в Shader Model 1 были очень сильно привязаны к железу NVIDIA. Аппаратной абстракции от NVIDIA не было вообше; SM 1.0 по сути был тем что делал GeForce 3.

Когда ATI вступили в гонку производительных графических карт со своим Radeon 8500, обнаружилась проблема. Пиксельный конвеер 8500 был мощнее чем у NVIDIA. И Microsoft выпустил Shader Model 1.1, который по сути был «тем что делал 8500».

Это может показаться провалом со стороны D3D. Но провал и успех это вопрос относительный. Настоящий провал происходил в стане OpenGL.

NVIDIA любили OpenGL, поэтому когда вышел GeForce 3, они выпустили комплект расширений OpenGL. Проприетартных расширений, подходящих только для NVIDIA. Естественно, когда вышел 8500, он не мог использовать ни одно из них.

Видите ли, в D3D v8 вы по крайней мере можете запустить шейдеры SM 1.0 на железе ATI. Естественно, чтобы использовать вкусности 8500 Вам придётся написать новые шейдеры, но Ваш код по крайней мере работал .

Чтобы получить хоть какие то шейдеры на 8500 в OpenGL, ATI пришлось написать несколько расширений OpenGL. Проприетартных расширений, подходящих только для ATI. Итак, Вам приходилось писать два пути выполнения кода, для NVIDIA и для ATI, чтобы иметь хоть какие то шейдеры.

Сейчас Вы наверняка спросите: «А чем занимался OpenGL ARB, чьей работой было поддержание OpenGL в актуальном состоянии?». Да тем же, чем занимаются большинство комитетов: тупил.

Видите ли, выше я упомянул ARB_multitexture потому что это тоже часть этой истории. С точки зрения внешнего наблюдателя ARB пытался вообще избежать добавления шейдеров. Они посчитали что если создать достаточно конфигурируемый конвеер с фиксированными фунцкиями он сможет сравняться по возможностям с шейдерными конвеерами.

И ARB стал выпускать расширение за расширением. Каждое расширение, в названии которого присутствовало «texture_env» было очередной попыткой залатать этот стареющий дизайн. проверьте реестр: между расширениями ARB и EXT таких вышло аж восемь штук. Многие вошли в основные версии OpenGL.

Microsoft в это время были участником ARB; они ушли примерно во время выхода D3D 9. Так что в принципе, вполне возможно что они каким то образом саботировали разработку OpenGL. Я лично сомневаюсь в этой версии по двум причинам. Во первых, им пришлось бы заручиться помощью других членов комитета, поскольку у одного участника только один голос. И, что более важно, во вторых, Комитету не нужен был Microsoft чтобы прийти к такому провалу. Чуть позже мы увидим что так и получилось.

Со временем ARB, скорее всего под натиском ATI и NVIDIA (очень активных участников) проснулся настолько чтобы принять шейдеры ассемблерного типа.

Хотите увидеть еще большую глупость?

Аппаратный T&L. Который в OpenGL появился раньше . Тут вот что интересно. Чтобы выжать максимальную производительность из аппаратного T&L, Вам необходимо хранить данные в GPU. В конце концов, именно в GPU они используются.

В D3D v7 Microsoft представил концепцию вертексных буферов. Это выделенные области памяти GPU для хранения данных о вертексах.

Хотите узнать когда в OpenGL появился свой аналог этого? О, NVIDIA, будучи фанатом всего что относится к OpenGL (до тех пор пока написанное остаётся проприетарным расширением NVIDIA), выпустили расширение для вертексных массивов еще при первом выпуске GeForce 256. Но когда ARB решил официально предоставить подобный функционал?

Два года спустя . Это случилось после того как они одобрили вертексные и фрагментные шейдеры (пиксели в языке D3D). Вот сколько времени заняла у ARB разработка кроссплатформенного решения для хранения данных в памяти GPU. Именно то, что нужно чтобы выжать максимум из аппаратного T&L.

Один язык чтобы всё разрушить

Итак, разработка OpenGL была раздроблена. Нет единых шейдеров, нет единого хранилища в GPU, когда пользователи D3D уже наслаждались и тем, и другим. Могло ли стать ещё хуже?

Ну… можно сказать и так. Встречайте: 3D Labs .

Кто они такие, спросите Вы? Это разорившаяся компания которую я считаю настоящими убийцами OpenGL. Естественно, общая вялось ARB сделала OpenGL уязвимым, когда он должен был бить D3D на всех фронтах. Но 3D Labs это возможно самая большая причина текущего рыночного положения OpenGL. Что они могли сделать такого?

Они разработали Язык Шейдеров OpenGL.

Дело в том что 3D Labs была умирающей компанией. Их дорогие ускорители стали ненужными когда NVIDIA усилили давление на рынок рабочих компьютеров. И, в отличие от NVIDIA, у них не было никакого присутствия на общем рынке; если бы NVIDIA победила, они бы исчезли.

Так и получилось.

И, в попытке остаться на плаву в мире, которому не нужна была их продукция, 3D Labs появились на Game Developer Conference с презентацией того что они назвали «OpenGL 2.0». Это должно было стать полностью переписанным с нуля API OpenGL. И это имело смысл; в API OpenGL было немало шероховатостей (примечание: они есть и сейчас). Просто посмотрите на что похожа загрузка и привязка текстур; это просто какая то чёрная магия.

Частью их предложения был язык шейдеров. Вот так. Однако, в отличие от текущих кросс-платформенных расширений ARB, их язык шейдеров был «высокоуровневым» (C это высокоуровневый язык для шейдеров. Нет, правда).

Итак, Microsoft в это время работали над своим собственным высокоуровневым языком шейдеров. Назвали они его, по своей давней привычке, «Высокоуровневым Языком Шейдеров» (HLSL). Но подход к языку был в корне другим.

Самая большая проблема языка шейдеров от 3D Labs была в том что он был встроенным. Видите ли, HLSL был языком, определённым Microsoft. Они выпустили для него компилятор, который генерировал ассемблерный код для Shader Model 2.0 (и последующих версий), который Вы вставляли в D3D. В дни D3D v9, HLSL никогда не вызывался из D3D напрямую. Он был удобной абстракцией, но совершенно необязательной. У разработчика всегда оставалась возможность отложить компилятор и доработать код до максимальной производительности.

В языке 3D Labs ничего этого не было. Вы скармливали драйверу код на C-подобном языке, и он возвращал шейдер. Всё, конец истории. И не ассемблерный шейдер, не то что можно вставить куда нибудь. Настоящий объект OpenGL, представляющий шейдер.

Это означало что пользователи OpenGL были беззащитны перед ошибками разработчиков, которые только начали разбираться с компилируемыми ассемблеро-подобными языками. Баги компилятора в новом языке шейдеров OpenGL (GLSL) ходили просто табунами . Что еще хуже, если Вам удавалось правильно скомпилировать шейдер для нескольких платформ (само по себе непростая задача), Вам всё равно приходилось иметь дело с оптимизаторами того времени. Которые были не так оптимальны, как могли бы.

Хотя это было главной проблемой GLSL, но не единственной. Далеко не единственной.

В D3D, как и старых ассемблерных языках OpenGL, можно было смешивать вертексные и фрагментные (пиксельные) шейдеры. Пока они использовали единый интерфейс, можно было использовать любой вертексный шейдер с любым совместимым фрагментным шейдером. Кроме того были уровни несовместимости, которые в принципе можно было терпеть; вертексный шейдер мог выдавать данные, которые фрагментный шейдер просто не читал. И так далее.

В GLSL ничего такого не было. Вертексные и фрагментные шейдеры были собраны в единую абстракцию, которую 3D Labs назвали «программный объект». И если Вам хотелось использовать вместе вертексные и фрагментные программы, Вам приходилось строить несколько таких программных объектов. И это было причиной второй проблемы.

Видите ли, 3D Labs думали что поступают очень умно. Они основали модель компиляции в GLSL на C/C++. Вы берёте.c или.cpp и компилируете в объектный файл. Потом Вы берете один или несколько объектных файлов и линкуете их в программу. Вот так и происходит компиляция в GLSL: вы компилируете шейдер (вертексный или фрагментный) в объект шейдера. Потом Вы помещаете этот объект шейдера в программный объект и связываете их вместе чтобы получить программу.

Хотя это позвляло делать некоторые потенциально крутые вещи вроде «библиотек» шейдеров, содержащих дополнительный код, который совместно использовали основные шейдеры, на практике это означало что шейдеры компилировались дважды. Один раз на этапе компиляции, один раз на этапе линковки. Не создавалось никакого промежуточного объектного кода; шейдер просто компилировался, результат компиляции выбрасывался и компиляция повторялась во время линковки.

Так что если Вы хотели связать Ваш вертексный шейдер с двумя разными фрагментными шейдерами, Вам приходилось компилировать куда больше кода, чем в D3D. Тем более что вся компиляция C-подобных языков происходила при разработке, а не при запуске программы.

У GLSL были и другие проблемы. Возможно неправильно винить во всём 3D Labs, потому что ARB в конце концов одобрила и приняла этот язык (но ничего кроме него из их предложения «OpenGL 2.0» не прошло). Но идея была именно их.

А вот действительно печальная часть. 3D Labs по большому счёту были правы . GLSL это не векторный язык шейдеров, каким всегда был HLSL. Так случилось потому что железо 3D Labs было скалярным железом (так же как современные карты NVIDIA), но в целом они были правы по части направления развития ускорителей.

Они также были правы с «compile-online» моделью для «высокоуровневых» языков. D3D впоследствии тоже на неё перешёл.

Проблема была в том что 3D Labs оказались правы в неправильное время . И в попытке призвать будущее слишком рано, в попытке его предугадать, они отбросили настоящее. Это также как OpenGL всегда имел возможность делать T&L. Если не считать того что конвееры T&L в OpenGL были полезны ещё до выхода аппаратной реализации, а GLSL был просто обузой прежде чем мир оказался готов его принять.

Сейчас GLSL - хороший язык. Но для своего времени он был ужасен. И OpenGL пострадал за это.

Приближается апофеоз

Хотя я и утверждаю что 3D Labs нанесли смертельный удар, именно комитет ARB забил последний гвоздь в крышку гроба OpenGL.

Эту историю вы наверняка слышали. Во времена OpenGL 2.1, OpenGL встал перед проблемой. У него было много старых неровностей. API было сложно использовать. Для каждого действия существовало по пять способов и никто не знал, какой окажется самым быстрым. Можно было «изучить» OpenGL по простым руководствам, но никто не говорил Вам какое API даст Вам максимум производительности.

И ARB решил сделать ещё одну попытку изобрести OpenGL заново. Это было похоже на «OpenGL 2.0» от 3D Labs, но лучше, потому что за ней стоял ARB. Попытку назвали «Longs Peak».

Что было не так с попыткой исправить старые API? Плохо было то что Microsoft в то время были уязвимы. Это было время выхода Vista.

В Vista Microsoft решили ввести давно необходимые изменения в драйверах дисплея. Они заставили драйверы обращаться к ОС для виртуализации видеопамяти и многих других вещей.

Хотя можно сомневаться в том было ли это необходимо, но факт остаётся фактом: Microsoft решили что D3D 10 будет только для Vista (и последующих ОС). Даже если у Вас было железо, способное выполнять функции D3D 10, Вы не могли запускать D3D 10 приложения без запуска Vista.

Вы также наверное помните, что Vista… ну, скажем просто что она получилась не очень. Итак, у Вас была тормозная ОС, новое API, работающее только на этой ОС, и новое поколение ускорителей которым было нужно API и ОС чтобы превзойти предыдущее поколение ускорителей.

Однако, разработчики могли бы получить доступ к фунциям уровня D3D 10 через OpenGL. Ну, смогли бы, если бы ARB не были так заняты работой над Longs Peak.

По большому счёту, ARB потратил полтора-два года на то чтобы сделать API лучше. Когда вышел OpenGL 3.0, время Vista уже заканчивалось, на горизонте появилась Win7, и большинство разработчиков уже не интересовались фунцкиями D3D-10. В конце концов, железо для которого предназначался D3D 10 замечательно работало с D3D 9. А с расцветом портов с PC на приставки (или PC-разработчиков, занявшихся разработкой для приставок) функции класса D3D 10 оказались невостребованы.

Если бы у разработчиков был доступ к этим функциям раньше, через OpenGL на машинах с WinXP, разработка OpenGL получила бы так необходимый импульс. Но ARB упустил эту возможность. И знаете что самое плохое?

Несмотря на то что два ценных года были потрачены на разработку API с нуля… они всё равно провалились и вынуждены были вернуться к предыдущей версии.

То есть, ARB не только упустили замечательную возможность, но и не сделали ту задачу, ради которой возможность была упущена. Просто полный провал.

Это и есть история борьбы OpenGL и Direct3D. История упущенных возможностей, огромной глупости, слепоты и просто безрассудства.

Всем привет! Что-то последнее время много уроков по конструкторам игр, и не так много по различным языкам программирования. Что бы устранить эту не справедливость, я решил запилить урок по OpenGL C++, надеюсь вы оцените)

Сразу же перейдем к геймдеву и будем писать маленькую игрульку нашего детства.

Для начала подключаем библиотеку OpenGL к своей среде разработки, я лично программирую в Microsoft Visual Studio 2013.

200?"200px":""+(this.scrollHeight+5)+"px");">
#include "stdafx.h"
#include
#include
#include
#include // подключаем все необходимые инклюды.

Int N = 30, M = 20; // т.к. змейка будем ездить по квадратикам, создадим их, для нашего окна в идеале будет 30x20 квадратов
int scale = 25; // размер квадрата. Когда OpenGL будет расчерчивать поле для игры, расстояние между гранями квадрата будет 25 пикселей

Int w = scale*N; // ширина поля
int h = scale*M; // его высота

Int dir, num = 4; // 4 направления и начальный размер змеи.
struct { int x; int y; } s; // структура змеи, X и Y координаты, массив с длинной.

Class fruct // класс фруктов, тех самых, которые будет есть наша змея
{
public:
int x, y; //координаты фруктов, что и где будет находится

Void New() // паблик с новыми фруктами. Он будет вызываться в начале игры и в тот момент, когда змея съест один из фруктов
{
x = rand() % N; // вычисление X координаты через рандом
y = rand() % M; // вычисление Y координаты через рандом
}

Void DrawFruct() // паблик, отрисовывающий фрукты
{
glColor3f(0.0, 1.0, 1.0); // цвет фруктов. в openGL он задается от 0 до 1, а не от 0 до 256, как многие привыкли
glRectf(x*scale, y*scale, (x + 1)*scale, (y + 1)*scale); // "Закрашиваем" квадрат выбранным цветом, таким образом в нем "появляется" фрукт
}
} m; // масив с фруктами, таким образом, у нас появится одновременно 5 фруктов в разных местах, а не один, как мы привыкли

Void Draw() // функция, которая отрисовывает линии
{
glColor3f(1.0, 0.0, 0.0); // цвет наших линий, в данном слуае - красный
glBegin(GL_LINES); // начинаем рисовать и указываем, что это линии
for (int i = 0; i < w; i+= scale) // отрисовываем линии в ширину
{
glVertex2f(i, 0); glVertex2f(i, h); // рисуем прямую
}
for (int j = 0; j < h; j += scale) //отрисовываем линии в высоту
{
glVertex2f(0, j); glVertex2f(w, j); // рисуем ту же самую прямую, но в другом направлении
}

GlEnd(); // конец отрисовки
}

Void tick() // функция в которой будет все обновляться (двигаться змея и т.д.)
{
for (int i = num; i > 0; --i) // движение змеи. Система остроумна и проста: блок перемешается вперед, а остальные X блоков, на X+1(2 блок встанет на место 1, 3 на место 2 и т.д...)
{
s[i].x = s.x; // задаем Х координату i блока координатой i - 1
s[i].y = s.y; // то же самое делаем и с Y координатой
}
// далее у нас система направлений.
if (dir == 0) s.y += 1; // если направление равно 0, то первый фрагмент массива перемещается на один по Y
if (dir == 1) s.x -= 1; // если направление равно 1, то первый фрагмент массива перемещается на минус один по X
if (dir == 2) s.x += 1; // аналогиная система
if (dir == 3) s.y -= 1; // аналогичная система

For (int i = 0; i < 10; i++) //цикл, в котором наша змея будет расти
{
if ((s.x == m[i].x) && (s.y == m[i].y)) // Если голова нашей змеи находится в одном блоке с фруктом, то...
{
num++; //...увеличиваем размер нашей змеи на 1
m[i].New(); // ... запускаем функцию отрисовки нового фрукта.
}
}
// Следующее нужно, что бы змея не выходила за рамка поля. Действует это просто: если змея выходит за рамки поля, то задаем
if (s.x > N) dir = 1; // Ей обратное направление. Например, если она выйдет за экран по высоте, то задаем ей направление, при котором она ползет
if (s.y > M) dir = 3; // вниз
if (s.x < 0) dir = 2;
if (s.y < 0) dir = 0;

For (int i = 1; i < num; i++) // с помощью этого цикла мы "обрежем" змею, если она заползет сама на себя
if (s.x == s[i].x && s.y == s[i].y) // проверка координат частей змеи, если X и Y координата головной части равно координате любого
num = i; // другого блока змеи, то задаем ей длину, при которой "откушенная" часть отпадает.
}

Void Snake() // выводим змейку на экран
{
glColor3f(0.1, 1.0, 0.0); //цвет змеи
for (int i = 0; i < num; i++) // цикл отрисовки.
{
glRectf(s[i].x*scale, s[i].y*scale, (s[i].x + 0.9)*scale, (s[i].y + 0.9)*scale); //Рисуем квадраты, те самые "блоки" змеи
}
}

Void Key(int key, int a, int b) // функция нажатия клавиш
{
switch (key) // используем оператор switch
{
case 101: dir = 0; break; // при нажатии клавиш, задаем направление змеи(вверх, вниз, влево, вправо)
case 102: dir = 2; break;
case 100: dir = 1; break;
case 103: dir = 3; break;
}
}

Void Display() //функция общий отрисовки
{
glClear(GL_COLOR_BUFFER_BIT); // очищаем окно перед началом отрисовки

Draw(); // вызов функции Draw, отвечающей за отрисовку фруктов
Snake(); // вызов функции Snake, отвечающей за отрисовку змейки

For (int i = 0; i < 5; i++) // заполнение карты фруктами
m[i].DrawFruct();

GlFlush(); // выводим на экран все вышеописанное
glutSwapBuffers();
}

Void timer(int = 0) // Таймер игры(промежуток времени, в котором будет производится все процессы)
{
Display(); // Вызов функций
tick();
glutTimerFunc(100, timer, 0); // новый вызов таймера(100 - промежуток времени(в милисекундах), через который он будет вызыватся, timer - вызываемый паблик)
}

Int main(int argc, char **argv) // Главная функция
{
std::cout << "Snake by Alexey Ovchinnikov:P\n Loading..."; // крутой текст в консоле при загрузке
srand(time(0));
for (int i = 0; i<10; i++) // начальная, самая первая отрисовка фруктов
m[i].New();

S.x = 10; // начальное положение змейки по X
s.y = 10; // и Y координате
// следующие функции абсолютно идиентичных почти во всех программах на OpenGL, так то запоминать их не обязательно, кроме...
glutInit(&argc, argv);
glutInitDisplayMode(GLUT_SINGLE | GLUT_RGB);
glutInitWindowSize(w, h); // ... этой, она создаем окно (w - ширина, h - высота)
glutCreateWindow("Game"); // ... этой, она задает название окна
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
gluOrtho2D(0, 640, 0, 480);
glutDisplayFunc (Display); // ... и этой, она вызывает начальную функцию, в нашем случае это главная функция отрисовки - Display
glutSpecialFunc(Key);
glutTimerFunc(50, timer, 0); // ... Ну и в начале программы задаем рекурсивный таймер.
glutMainLoop();

Return 0;
}

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

Во время своего #shaderchallenge (заинтересовался как устроена красивая графика, какие визуальные эффекты можно делать шейдерами и тд,- и решил непременно изучить) я пришел к тому, что мне необходимо знать как устроены внутри игровые движки. И, конечно, нет способа лучше изучить устройство чем попробовать написать свой!

Так сказать позаколачивать знания в свою голову, наступая на разные грабли, изгугливая разные форумы, доски и тп.

В 2016ом я решил прокачаться в программировании графики и начал изучать программирование шейдеров. И как оказалось в этом деле никуда без математики, поэтому я хорошую часть этого года вспоминал, а по-большей части заново знакомился с линейной алгеброй и кое-каким мат. анализом.

С какими-то простыми эффектами я познакомился в Unity3d, я по роду своей деятельности программирую именно на этом движке. Делал скринэффекты, простой аутлайн и тп. Кстати, знание того, как устроен пайплайн и какие эффекты можно получить, развязывают руки и в некоторых ситуациях просто думаешь: — Ага, так можно вот шейдерочек написать.

Но, как я говорил выше, необходимы более глубокие знания. Пишу свой движок. Конечно на C++ и OpenGL. Не DirectX, потому, что мне казалось, что на консолях именно OpenGL, но это не так.

Все говорят, что OpenGL и DirectX очень похожи, а я понимаю, что главное это понимать концепции и подходы, а фреймворк освоить можно быстро. Поэтому перескакивать на DirectX я не стал.

Про графическую библиотеку пояснил. Теперь про язык. Я очень доволен выбором именно C++, какой он крутой, ребята! Сколько всего я о нем не знал! Сколько добавилось в новых стандартах и сколько еще предстоит изучить!

Итак, встречайте, первое более-менее презентабельное демо, в моей собственном игровом движке Rudy Engine.

Первое демо

Реализовано: cubemap/skybox, загрузка моделей через assimp, half-lambert для освещения, overlay-рендерер для прицела и маркера-указателя на космическую станцию.

(очень дрожит видео, не стал искать какую-то хорошую программу для записи, воспользовался monosnap, наверное он не очень для этого подходит)

Дальнейшие планы

В дальнейшем я хочу сделать туман, shadow-mapping, и какие-то эффекты для этой демки и, возможно, переключиться на какую-то следующую. В целом, стараюсь придерживаться взрослой и мучительной разработки: дорабатывать движок таким образом, чтобы старые демо оставались рабочими. Подрихтовываю и подлатываю его. Для чего? Нужно понять этот trade-off как у Unity, чего стоит сделать универсальный инструмент?

Update 2017

Летом в 2017ом году, у меня закончился испытательный срок в крупной игровой студии и я написал в блоге, вся вот эта практика с игровым движком, мне очень помогла!

Конечно, Go не задумывался как язык для написания игр. Но чем еще заняться холодными осенними вечерами? Давайте попробуем запустить несколько игровых движков и посмотреть, как в Go-мире обстоят дела с геймдевом.

GarageEngine

Наш первый экземпляр - это 2d игровой движок для Go, который работает на OpenGL. Он состоит из модулей/компонентов. Сейчас уже есть приличное количество таких модулей для шрифтов, спрайтов, текстур, физики, сцен и так далее. Очень сильно ощущается влияние Unity3d. Особенно в названиях компонентов: Scene, Coroutines, Components, Transform, GameObjects и т.д.

К сожалению это проект для обучения. Не стоит ожидать от него супер-килер-фич и обратной совместимости.

Установка

Нам нужно установить либы glfw и glew

Sudo apt-get update sudo apt-get install build-essential binutils-gold \ freeglut3 freeglut3-dev libalut-dev libglew-dev \ libglfw-dev libxrandr2 libxrandr-dev

Если вы используете windows вам нужно юзать mingw и собрать glew.

Go get github.com/vova616/GarageEngine

Примеры

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

Прежде всего заходим в папку src/github.com/vova616/GarageEngine и собираем все руками:

Go build main.go

Если появилась ошибка вида:

# github.com/vova616/GarageEngine/engine/audio .godeps/src/github.com/vova616/GarageEngine/engine/audio/AudioSource.go:129: undefined: openal.DistanceModel

Комментируем строки 128-130 в файле src/github.com/vova616/GarageEngine/engine/audio/AudioSource.go

If currentDistanceModel != this.distanceModel { openal.SetDistanceModel(openal.DistanceModel(this.distanceModel)) }

Пытаемся запустить и получаем ошибку listen tcp 0.0.0.0:123: bind: permission denied . Меняем номера портов в файле src/github.com/vova616/GarageEngine/spaceCookies/server/Server.go на строке 88

Addr, err:= net.ResolveTCPAddr("tcp", "0.0.0.0:12345")

и в файле src/github.com/vova616/GarageEngine/spaceCookies/game/Client.go строки 19 и 20

Const ServerIP = "localhost:12345" const ServerLocalIP = "localhost:12345"

Опять пробуем запустить и ничего не получается. Рядом с нашим бинарником лежит файл log.txt c примерно таким содержимым:

Enginge started! GLFW Initialized! Opengl Initialized! open ./data/spaceCookies/background.png: no such file or directory open ./data/spaceCookies/button.png: no such file or directory runtime error: invalid memory address or nil pointer dereference panic.c:482, os_linux.c:234, Sprite.go:42, LoginScene.go:83, Engine.go:96, main.go:78, main.go:44, proc.c:220, proc.c:1394

Видим, что программа пытается найти файлы./data/spaceCookies/background.png и./data/spaceCookies/button.png . А папка, на самом деле, называется./data/SpaceCookies . Переименовываем папку и снова запускаем. Ура! Теперь все работает.

☣ Azul3D

Azul3D это 3D движок написанный полностью с нуля на языке программирования Go. Azul3D подходит для создания 2D и 3D игр. Так же, его можно использовать для создания не игровых, а просто интерактивных приложений. В отличии от большинства современных движков(таких как Unity, JMonkey) у Azul3D нет дополнительных фич типа редакторов уровней, IDE. Это просто набор необходимых разработчику пакетов.

Это игровой движок от программистов для программистов. Он очень минималистичен, но легко расширяется в отличии от других движков.

Azul3D предоставляет самые необходимые инструменты, которые будут использоваться изо дня в день. И делает это действительно хорошо.

Установка

Начинаем с зависимостей для Ubuntu 14.04. Для других систем .

Sudo apt-get install build-essential git mesa-common-dev \ libx11-dev libx11-xcb-dev libxcb-icccm4-dev \ libxcb-image0-dev libxcb-randr0-dev libxcb-render-util0-dev \ libxcb-xkb-dev libfreetype6-dev libbz2-dev \ libxxf86vm-dev libgl1-mesa-dev

Примеры

Теперь пробуем установить примеры. Они вынесены в отдельный пакет.

Go get azul3d.org/examples.v1

нам понадобится куча других пакетов:

Go get azul3d.org/keyboard.v1 go get azul3d.org/lmath.v1 go get azul3d.org/gfx.v1 go get azul3d.org/gfx/window.v2 go get azul3d.org/mouse.v1 go get azul3d.org/tmx.dev

Теперь можем посмотреть примеры. Заходим в src/azul3d.org/examples.v1/azul3d_tmx и запускаем пример

Go run azul3d_tmx.go

Вы увидите что-то такое:

Были проблемы с версией Go ниже 1.3. Обновился до самой последней и все отлично заработало на моей ubuntu 14.04.

gosfml

Возможность использовать C-код в Go приложениях - это просто прекрасно. Мы можем использовать кучу готовых библиотек.

И конечно же, нельзя обойти стороной Go биндинги к популярной библиотеке SFML . Есть несколько вариантов, но я смог запустить только этот .

SFML - это кросплатформенная библиотека для мультимедиа. Она написана на C++, но есть куча привязок к разным языкам и к Go в том числе.

Кроме работы с мультимедиа в этой либе есть несколько пакетов для программирования простых игр.

Модули, которые нам доступны в этой библиотеке:

• System - управление временем и потоками.
• Window - управление окнами и взаимодействием с пользователем.
• Graphics - делает простым отображение графических примитивов и изображений.
• Audio - предоставляет интерфейс для управления звуком.
• Network - для сетевых приложений.