разработка

Подводя итог, я писал эту игру на DirectX 9, и моим лучшим результатом был такой:

Непрозрачные: 1,87 мс Прозрачные: 16,49 мс Всего: 18,36 мс Частота кадров: 54 fps
Мне нужна была функция под названием текстурные массивы, которых не было в DX9, поэтому я решил попробовать OpenGL. Моя первая версия, использующая ту же логику, что и версия DirectX (без текстурных массивов), добилась таких результатов:

Непрозрачные: 1.95 ms Прозрачные: 27.19 ms Всего: 29.14 ms Частота кадров: 34 fps
Это было гораздо медленнее для прозрачных данных. Это тот же самый код, который генерирует тот же самый список треугольников, занимающий столько же места, поэтому там точно такой же объем работы. Хотя я не копался в нем, я предполагаю, что есть некоторые дополнительные накладные расходы в Windows, чтобы добраться до вызовов OpenGL, и добавление более тысячи отдельных треугольников замедляет процесс.

В последней части я пытался ускорить код рендеринга, чтобы отобразить больший мир. Вот мои последние показатели:

Непрозрачные: 1,87 мс Прозрачные: 16,49 мс Всего: 18,36 мс Частота кадров: 54 fps
Чтобы сделать еще быстрее, мне были нужны массивы текстур. Я подумал, что это ускорит рендер прозрачных деталей еще на 5 мс, что было бы неплохо, но несущественно. Чтобы получить эту возможность, я мог либо перейти на DX 10, либо переключиться на OpenGL, либо посмотреть, смогу ли я сделать все сам в шейдерах с DX 9.

Так как использование OpenGL потенциально могло бы дать мне пользователей MacOS и Linux без потери пользователей Windows XP, я решил изучить его последнюю версию (я игрался с версией 1.1 много лет назад). Я купил электронную копию OpenGL SuperBible и начал работать с ней. Это заняло почти всю неделю.

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

Я начал неделю с работы над загрузкой и выгрузкой блоков данных кубов по мере того, как вы перемещаетесь по миру. Это просто. Что сложнее - так это быстро отрисовывать данные кубов и создавать уменьшенную детальную версию для использования на расстоянии. Такова тема этой части.

Несмотря на мое намерение реализовать большой мир, который будет страницей в кусочках пейзажей по мере продвижения, я отвлекся на все комментарии по последней части, как на этом сайте, так и на Twenty Sided Blog Самуса Янга. Я провел большую часть недели, пытаясь придумать лучшее видение моего мира.

Как я уже говорил, у меня художественная отсталость, так что это трудно для меня. Единственное исскуство, что я делал после детского раскрашивания карандашами - это фотография. И даже там я никогда не разрабатывал никакой техники. Мое правило - "Ходи в живописные места. Делай много фотографий. Оставляй хорошие".

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

Мы хотим (полу-) бесконечный мир, а для этого нужна работа. Сначала давайте рассмотрим требования:

В шестой части я решил, что хочу, чтобы игровой "мир" состоял из поля астероидов, чтобы у игроков был повод собраться в кучу. Я не хочу, чтобы люди расползались во всех направлениях и никогда не встречались друг с другом.

Итак, следующий вопрос - насколько большим должен быть астероид? В данных Minecraft, с которыми я играл, я импортировал блок 128 на 128 на 128. Это достаточно много материала для одного человека, чтобы строить (это более двух миллионов кубов). Если я хочу поддержать 500 человек на астероиде, каждый с таким количеством кубов для игры, есть два способа вычислить размер астероида.

Если делать это по площади, то 128 на 128 на 500 человек - это 8 192 000 кубиков. Сфера с такой площадью поверхности имеет радиус 807 единиц. Но я предполагаю, что люди будут закапываться в астероид и строить подземные города, или выдолбить центр и заполнить его городом, оставив поверхность как парк и т.д. Если делать расчет по объему, то куб 128 на 128 на 128 для 500 человек - это 1 048 576 000 кубов, но сфера с таким объемом имеет радиус всего 630 единиц.

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

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

Я интегрировал это в мой (медленный) трассировщик лучей. Затем мне нужно было расположить камеру и лететь в поисках фильма. Для этого я добавил функцию в демо-версию моего кубического мира. Я могу летать в этом мире, и с помощью функциональной клавиши записывать текущее положение и углы камеры в файл. Это дает мне возможность легко проложить путь камере. Затем трассировщик лучей считывает этот файл и создает отдельные кадры, 30 в секунду, вдоль пути камеры. Достаточно просто.

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

Однако мне также не очень нравится просто махать рукой и говорить "мир расширяется пользователями - он может выглядеть так, как вы хотите. Там можно писать программы. Это будет здорово". Это никого не убедит, и не даст мне ни тестеров, ни предложений. Это просто большая пустая доска. Так что мне нужно построить что-то, на что люди смогут отреагировать.

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

Мне не нужен централизованно управляемый мир, где дизайнер решает все о стиле игры. Кроме того, я не могу позволить себе управлять серверной фермой и поддерживать миллион пользователей. И у меня все равно нет ни художественных, ни дизайнерских талантов, чтобы построить игру мирового уровня. Поэтому моя идея заключается в том, чтобы сделать мир равноправным и позволить программирование и дизайн в мире. Тогда он сможет расширяться и меняться, основываясь на том, что люди хотят там делать. Подумайте о peer to peer Lego Universe, с редактором для создания новых блочных типов и языком программирования, который позволит вам добавлять игры или приложения в мир.

Текстуры, которые мы используем, задаются в красном, зеленом и синем каналах. Дисплей также поддерживает четвертый "альфа" канал, который может быть использован для реализации прозрачности. Библиотеки DirectX (и OpenGL) на самом деле поддерживают всевозможные правила для комбинирования новой текстуры с тем, что уже есть на экране, но, наиболее распространенным является линейное комбинирование умножением на альфа-значение.

Например, если бы альфа была 0.0, вы бы получили весь существующий пиксел экрана, и ничего из новой текстуры. Это можно использовать для маскировки нежелательных частей текстуры и превращения ее в полностью прозрачную. В другой крайности, значение 1.0 не будет использовать ни один из существующих пикселей экрана, зато возьмет всю новую текстуру, что сделает ее непрозрачной. Значения посередине дадут вам полупрозрачный эффект.