Вообще, тема создания собственного графического движка для игры достаточно больная и давно заезженная. Я решил включить её в уроки на моём блоге, т.к. многие всё равно, так или иначе, возьмутся делать собственный графический движок. Кроме того, это блог в том числе по программированию графики, потому лишним не будет. Ну и, конечно, создание игры, особенно достаточно простой, нередко подразумевает и создание граф. движка, т.к. простой движок создать достаточно не сложно, а времени сэкономить он может кучу.
Со своей стороны обещаю, что наш графический движок не будет многоруким шивой и мы создадим его максимально компактным и простым. А так же, что на создание этого графического движка для игры у нас не уйдёт слишком много времени – нам же надо в первую очередь сделать игру, а не графический движок.
Итак, какой же минимум работы мы сможем поручить созданному нами графическому движку для игры? Давайте прикинем, что бы нам хотелось:
Что бы весь код инициализации графики был скрыт в самом движке.
Если вдруг произошёл LostDevice (например, такое бывает при запуске скринсейвера или блогкировке компа), что бы движок сам восстанавливал все нужные данные (например, текстуры).
Мы хотим одной функцией завершать всю работу с графикой и выгружать все ресурсы
Пока этого хватит.
Итого получается, текстура:
Шейдеры:
Кода, вроде, немало, но, мне кажется, всё должно быть понятно из комментариев. Мы вынесли текстуры и шейдеры в отдельные классы, что бы полностью скрыть их реализацию от пользователя движка – так в дальнейшем будет проще программировать. Кроме того, мы сможем не думать о таких вещах, как загружена ли уже нужная нам текстура, что делать при LostDevice и так далее. В общем, просто удобство и, следовательно, скорость программига в будущем.
Теперь сам графический движок:
Для начала нам этого хватит. Конечно, этот получился очень примитивный движок – в нём нет умных указателей, счётчиков ссылок, нет приоритетов ресурсов, нет многопоточности, нет даже элементарной возможности выгрузить уже не нужную текстуру. Но нам это сейчас и не нужно. В следующих уроках мы будем постепенно наращивать возможности и, со временем, получим достаточно универсальный и удобный движок. Текущих же возможностей нам вполне хватит для создания несложных игр. А это, согласитесь, уже немало, учитывая, что на всё про всё мы потратили всего полчаса работы…
Вопрос по коду, в цикле, где обрабатываются windows message и код игры, мы каждый кадр заново устанавливаем все матрицы, рендер стейты и прочее.
А почему нельзя это выставить один раз перед тем, как войти в цикл?
Antony, вынести это всё можно и вызывать однократно тоже можно. Но:
1) в реальной боле-мене сложной игре это скорее всего не получится, т.к. там куча изменений стейтов и матриц во время рендера каждого кадра
2) если таким образом вы надеетесь “прооптимизировать” программу – не стоит, толку (буста) от этого не будет
супер
Вопрос по коду, в цикле, где обрабатываются windows message и код игры, мы каждый кадр заново устанавливаем все матрицы, рендер стейты и прочее.
А почему нельзя это выставить один раз перед тем, как войти в цикл?
Antony, вынести это всё можно и вызывать однократно тоже можно. Но:
1) в реальной боле-мене сложной игре это скорее всего не получится, т.к. там куча изменений стейтов и матриц во время рендера каждого кадра
2) если таким образом вы надеетесь “прооптимизировать” программу – не стоит, толку (буста) от этого не будет
А можно написать в какой очереди их читать а то как то непонятно где 1 урок, а где 2
Читать просто от старых уроков к новым. Справа в меню есть так же “Уроки DirectX” и “Уроки создания игр” – там последовательность чтения указана.
спасибо ещё 1 вопросик wstring это какой файл подключать?