Вот и свершился переезд блога на выделенный виртуальный сервер. Думаю теперь будет горздо меньше проблем с даун таймом, да и работать получше должно все.
Одновременно с эти начал работать над NYP2009, если всё удастся так, как задумано, то это будет шаг вперед, а вот если неудастся… ну за неделю сделать экстренный вариант я конечно успею)
Подсистема вывода графики движка MagicEngine.
Изначально вывод графики в движке был ориентирован на строго одну платформу и несоклько раз полностью переписывался. Со временем возник интерес сделать систему с подключаемыми модулями(драйверами) вывода видео — что и используется в данный момент.
Исторически использовалось несколько подходов к отрисовке 2д графики в движке:
1. Прямой доступ к видео памяти/экранному буферу: данный метод использовался во времена DOS(защищенный режим), Windows98 (DirectDraw) огромным минусом такого подхода является необходимость написания довольно большого объема кода для управления выводом графики и достаточно низкая производительность. Все данные хранятся в оперативной памяти и посылаются на отрисовку по готовности — а значит для разрешения 1024*768 отсылается 3 мегабайта данных на каждый кадр, что весьма сильно ограничивает скорость. К томуже все операции со спрайтами производятся на ЦПУ, который выполняет и другие задачи.
2. С переходом в ОС Linux данный метод был ликвидирован и ему на смену пришел кросплатформенный SDL в котором я также столкнулся с проблемами скорости, да и сама библиотека оказалась слишком монструозной.
В данный момент я остановился на модульной системе вывода графики и в качестве основного драйвера — использование OpenGL для отрисовки спрайтов. Конечно спрайты отрисованные таким образом могут получить некоторые дефекты — но с другой стороны можно получить гораздо большую скорость.
Чтоже такое MagicEngine который я использую в своей разработке.
Некоторое время назад, лет 5-6 когда я только начинал программировать я начал писать этот движок. Он эволюционировал по следующей схеме: DOS(защищенный режим)->WinAPI->SDL->GLUT->самопальная система для создания окон(OpenGL)->Кросплатформенный с использованием glfw и OpenGL . Изначально движок разрабатывался как 2Д что сохранено по сей день, его цель — легкое создание 2Д игр.
Добрался я до реализации монстров в своем маленьком проектике. Задача простая. Я хочу сделать чтобы небыло уровней, тоесть игрок имеет непрерывный геймплей который постепенно изменяется. При этом возникает сложность с тем что нельзя сделать заранее заданную карту по принципу «тут поставим 20 мобов таких, тут 10 таких, тут бос левел закончен». Игра может длиться неограниченное время и должна постепенно усложняться. Значит надо чтобы мобы появлялись динамически.
Вариант решения — поставить рандом выкидывающий мобов — это плохо, можно получить абсолютно не предсказуемые результаты типа двух босов подряд.
Значит надо делать чтото другое.
Покачто мысль дошла только до эмиттера мобов.
Т.е. создаем неки невидимый объект за пределами экрана. На каждый кадр он получает управление и решает — надоли создавать нового монстра. У него должны быть ограничения — неможет быть более N одинаковых монстров одновременно, вероятность появления моба M и другие условия, которыми можно управлять генерацией мобов.
Но чтоже такое сам моб. Моб — это самостоятельный объект незнанющий ничего об эмиттере. После его создания он должен двигаться по заранее заданному алгоритму (например по направлению к игроку) и выполнять указанные действия. Он должен понимать ситуацию попадания в него.
Об попаданиях позже, за сим все. Может у кого есть более интересные идеи по реализации монстров в аркаде?
Первый скриншот) Ужасный но зато первый
Учитывая что арта на данный момент нет никакого, все картинки взяты из Chromium B.S.U. В будущем планируется сделать таки выстреле через эмиттеры
Вот и добрался я до реализации стрельбы в своей маленькой игрушке.
Взаимодействие различных объектов, в игровом движке MagicEngine, построено на сигналах. Каждый объект имеет некоторые слоты, которые могут получать параметры и сигналы.
Каждый сигнал может быть подключен к одному и более слотам, что позволяет обрабатывать от одного сигнала несколько действий, например сигнал отрисовки нового кадра привязан к слотам счетчика кадров, управления движением снарядов, счетчика фпс (в будущем).
Система сигналов построена так, что сцены получают сигналы верхнего уровня — от видео драйвера и перенаправляют их объектам сцены.
В такой схеме сцена обязана получать сигнал нажатия мышькой чтобы уметь правильно выделить объект, на который было произведено нажатие мышкой. При нахождении такого объекта он становится активным и ему посылаются все остальные сигналы (движение мышки, нажатие кнопок) кроме сигнала нажатия кнопки мыши, потомучто при нажатии мыши мы могли хотеть сделать чтото другое, например нажать другую кнопку меню. Фактически это означает что объект «корабль» не может получить сигнал нажатия мыши и произвести выстрел на прямую. Поэтому для реализации стрельбы был использован промежуточный сигнал, что, кстати, очень удобно. Теперь появилась возможность посылать этот сигнал нескольким объектам. Конечно это осложняет задачу hot-seat, но она решается с привязыванием сигналов к игроку.
Итак, реализация стрельбы в архитектуре сигнал-слот.
Имеется два объекта: Hero(это кораблик которым управляет игрок) и Ammo( это собственно говоря и есть сам выстрел, картинка выстрела).
По логике вещей при выстреле игрока объект Hero должен создать новый объект типа Ammo, который должен привязаться к сигналу нового кадра, и забыть про него. Дальнейшие действия выпущенного снаряда решаются самим объектом Ammo, к примеру именно он будет определять столкнулся ли он с врагом и посылать врагу сигнал hit(попадание).
Для реализации этого были сделаны следующее:
В целях блокирования спамеров пришлось покопаться в настройках WordPress, заодно и подтюнил слегка.
Нашел интересную опцию и включил ее, теперь чтобы каждое сообщение от любого человека будет требовать премодерации до тех пор, пока хотябы одно его сообщение не будет одобрено. По идее это должно спасти от злобных спамеров, которых за несколько дней существования уже было 3 или 4 штуки.
Заодно поигрался с темкой и подключил древовидные каменты, теперь можно отвечать на коментарии, как мне этого не хватало)
Последовал совету Hyborg и написал генератор классов из xml в cpp с помощью xslt.
Впринципе xslt оказался достаточно простым для человека который ни разу с ним не работал.
Приветствуются мысли о том, как можно это сделать проще 🙂
Вообще это вещь нужная всегда. Былобы неплохо всегда иметь возможность получить информацию о производительности отдельных модулей, сколько вызовов чеголибо было произведено, чтобы можно было легко находить узкие места реализации, тормозящие все приложение.
Но сейчас пойдет речь не об общем варианте счетчика, а об одном специализированном: счетчик FPS.
К любому PerfomanceCounter, который планируется оставить в релизной версии, всегда следует применять требование быстродействия, тобишь он не должен работать медленно. Но вот критерий медленно слегка условен)
На данный момент думаю реализовать так: считать время за которое отрисуется 150 кадров. При скорости в 30 фпс это дает обновление раз в 5 секунд.
Еще была идея считать время отрисовки 1 кадра, но по моему тут будет слишком большой оверхед, хотя такой счетчик былбы удобен, если вести статистику по последним N кадрам — для определения моментов, в которые произошло «замирание».
Итак счетчик FPS:
Будет содержать 1 параметр: кол-во кадров для которых надо рассчитать время и 1 слот — новый кадр. Строить его надо явно на основе уже имеющегося scorefield, который переименовать в counter )
Итак, решил составить список ближайших планов по разработке.
На данный момент впринципе неважно, по какому принципу будут создаваться объекты, главная задача — получить хоть какуюто техническую демку.
Что должно в нее войти: кораблик, который умеет стрелять по нажатию мышки и двигаться в разные стороны. Монстров добавим в следующей версии.
На данный момент наиболее интересно именно получить что-то, пусть и не особенно играбельное)
Что для этого осталось сделать:
За код я не брался уже несколько недель, наверное под месяц, пора прекращать лентяйничать и начинать писать.
