Сборка контента через msbuild

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

А я разобрался как собирать контент для XNA без использования студии. Для этого надо проделать такое:

1. Взять msbuild (он в /Windows/Microsoft.NET/..., не в Program Files.


2. Добавить в contentproj
   
   <Import Project="$(MSBuildExtensionsPath)\Microsoft\XNA Game Studio\Microsoft.Xna.GameStudio.targets" />
<Import Project="$(MSBuildExtensionsPath)\Microsoft\XNA Game Studio\Microsoft.Xna.GameStudio.ContentPipelineExtensions.targets" />


3. Запустить msbuild с ключами /p:XNAContentPipelineTargetPlatform=Windows /p:XNAContentPipelineTargetProfile=Reach


4. Сжатие контента: /p:XNACompressContent=true

И на выходе в папке bin будет собранный контент. Если собирать проект весь, не только контент, то достаточно запустить msbuild в папке где лежит csproj игры.

Теперь дело за малым - интегрировать всё это с контролем версий, чтобы игра собиралась автоматом при заливании изменений. Автоматизация, хо!

Ну вот и всё

http://forums.create.msdn.com/forums/t/91616.aspx - будущее XNA туманно. Оно не будет жить на WinRT, скорее всего не будет поддерживать планшетники и WP8. Официально рекомендуется использовать WinRT/C++/DX11 для планшетов. Пока я сделаю игру под WP7 (анонс чере пару недель, следите за эфиром) и скорее всего начну делать крутой Ъ-фреймворк для игр на DX11 и с поддержкой WinRT в уме. А C# такой приятный язык.

Jamestown

Казуальное непотребство. Играть можно с любого открытого уровня, сложность ниже Divine следует считать изимодом. Divine не крут - любой уровень сдаётся максимум с первого-второго десятка попыток. Более-менее весело только на Judgement.

Но всё это по меркам жанра, на фоне типичных нынешних игрушек тут хардкор.

CLRProfiler и XNA

Если вдруг CLRProfiler стал падать при запуске XNA-игрушек то надо запускать его из командной строки из той же папки где лежит exe. Причина - XACT не очень хорошо дружит с определением рабочей папки, не может найти звук и кидает исключение.

Оживить торрент.

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

Flash вообще и AS3 в частности говно лютое, всех кто его использует по собственной воле следует физически уничтожить, они не люди вообще. Тех кто придумал - растворить заживо в кислоте с прямой трансляцией в стерео на весь мир. Пидараса что не сделал опцию "я ебал ваши вектора, скейлинг-хуельник и прочее говно, хочу чтобы было M на N пикселе и всё было в них" вообще больно-больно убивать, потом вылечить, потом снова убивать и так пока не дойдёт до абсолютно нелечибельного сосотояния.

Столкновения.

Сделал столкновения через BSP-дерево. За основу взят код найденный на AppHub, переделан на построение дерева для каждого меша, сохраняется вместе с моделью. В рантайме считается проверка на пересечение с Bounding Sphere, затем перевод в систему координат модели и проверка столкновения с деревом. Профайлер показывает что со скоростью всё в порядке. Сотня проверок на кадре и функция определения столкновений сидит где то в средней части. Минус сейчас - генерация мусора, надо найти реализацию LinkedList которая бы лучше работала с памятью. Или оставить как есть если сборка мусора не будет вызывать проблем.

Новые материалы.

Теперь вариант с полной подготовкой материалов в оффлайне реализован. Всё исходит из того что у меня конечное и неизменное число источников света и явное разделение на объекты первого и заднего плана. Текстуры и параметры материала в рантайме менять нельзя, материалов как таковых в коде нет, есть только параметры задаваемые снаружи, такие как матрицы и источники света. Преимущества подхода: тривиально в рантайме, не нужно использовать свой класс моделей и материалов.

Реализация проста. Наследуется MaterialEffect и MaterialEffectContent, в ConvertMaterial ставится эффект с зашитыми в него параметрами и текстурами. У наследника появляется ровно одно поле - техника. Техника определяется по наличию текстур и параметров на меше, сохраняется в материал. При загрузке мы просто грузим MaterialEffect, текстуры и параметы уже получаются установленными. Потом ставим нужную технику. И на этом всё, далее достаточно использовать стандартный код для рисования, точно как с BasicEffect, только внешних параметров чуть больше.

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

Методику можно развить: сохранять не одну технику а кучу разных, в зависимости от типов и числа источников света, теней и прочих. В рантайме выбирать нужную исходя из внешних параметров, в эффекте при этом будет что то типа "параметры -> техника".

Совершенно новая идея. Надо прямо при сборке ресурсов делать батчи. Сортировать MeshPart по эффектам, собирать части с одинаковыми эффектами вместе, ставить флажки типа "прозрачно/непрозрачно". Делать этим батчам какие нибудь id'ы для объединения одинаковых и рисования через инстансинг. Много подобных идей, непонятно как подходить пока.

Yet again.

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

Самый вопрос в том как к этой красоте прикрутить автоматические тесты.

Система материалов

Разрабатываю систему материалов для своего убердвижка на XNA. Будут убершейдеры и две модели света.

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

Первая модель света предназначена для основного действия. Всегда есть 3 направленных источника света, соответствует стандартной модели освещения используемого в фотографировании.

Вторая модель света используется для фона. Один направленный источник есть всегда. Один точечный источник служит для света от взрывов и эффектов на переднем плане.

Будет до 5 текстур для каждого материала. Диффузная, нормаль, спекуляр, излучение и детализация. Каждая текстура может быть анимирована по UV, это должно дать возможность делать разные крутые эффекты. Свет намерен считать по Кук-Торренсу.

Главной проблемой может быть невозможность впихнуть всё в один проход пиксельного шейдера, я пока не специалист в этой области. Второй проблемой - комбинаторика, шейдеров может быть очень много. К примеру точно придётся считать все текстуры анимированными с нулевой скоростью по умолчанию. Так же вопрос про необходимость наличия нескольких UV-координат на мешах.

Глубже.

Рабираюсь с XNA, оно заебись что такое. Первый взгляд на котором типично останавливаются и возвращаются клепать "уберэнжин" на OGL/DX/что-там-ещё ошибочен. Базовые возможности действительно пригодны в основном для демок и реально быстрой разработки, когда важно чтобы оно вообще заработало. Нужно идти глубже.

Самая писечка на текущий момент мне видится в связке Content Pipeline - игра. Первым сделал генератор спрайтовых атласов, спрайты переменого размера, скалдываются в кучу текстур, всё сохранятеся в один файл. Для доступа на atlas["имя спрайта"] получаем номер текстуру и область на текстуре для спрайта. Между отдельными элементами - 1 пиксель свободен, всё как положено.

Второе - генератор убершейдеров, пока с бинарными пинами. Генерирурет все возможные комбинации, складывает в файл, доступ по принципу Effect effect = ubershader[pin]. Хотел сделать крутую систему материалов, пока забил, нет надобности. Система построена на добавлении в текст шейдера описания возможных пинов. Далее можно добавить не-бинарные пины и указания несочетаменмых комбинаций.

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

Желания возвращаться на всякие там плючы нет уже вообще. Надо идти глубже.

По моему slackware и бубунта единственные линуксы что не поддались на коллективное петросянство. Даже Arch зашкварился. С учётом того что бубунта происходит от петросянов-дебилов дебиана то её дни сочтены. Нету больше линуксов.

Идиоты завели новую моду. Берём произвольную js библиотеку делающую круто или красиво. Идём на родной сайт. И пробуем найти документацию. Демки - сколько хочешь. Список "кто использует" - ещё больше. А ссылка на банальное описание параметров и что как делается спрятано где нибудь в жопе.
Надеюсь что разработчиков в аду черти будут насиловать вилами в зад до конца вселенной, а то что авторов надо убить при первой же возможности даже не обсуждается.

TinyMCE

Говно. Вообще за неспособность делать html руками и потребность в таких редактрах следует разжаловать из звания "человек" и отправлять в зоопарк, в клетку "говорящее животное". Или просто убивать на месте.

В ссаном MySql нет EXCEPT. Найти того кто это придумал и убить нахуй.

Угадайте кто вернулся в эфир.