XNA Content Pipeline: Обзор (комментарии)

XNA Content Pipeline: Обзор (комментарии)

Это сообщение сгенерировано автоматически.

Конструктивная критика приветствуется.
Если какая то часть статьи вам (вдруг) покажется запутанной или не совсем понятной
- говорите =)

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

основное преимущество пайплайна в том, что контент компилируется в классы .net и хранится как сериализованные объекты. ну ты об этом говорил...

Bonus
>нельзя ссылаться из проекта пайплайна на проект игры, иначе будет циклическая ссылка, поэтому приходится выносить все классы
Об этом кокраз есть по одной из ссылок в конце статьи, у Shawn Hargreaves в блоге. Там насколько я понял, как вариант, класс до XNB и после - может быть совсем разным. CustomModelContent  и CustomModel, так вроде и сделаны стандартные классы у пайплайна.  Но если нужно иметь общий класс, то он тоже рекомендует выносить в отдельный проект.

>нельзя отлаживать код пайплайна, без бубна.
Так и есть. Но это логично, пайплайн не работает в рамках приложения, а запускается как часть студии,
получается, что нужна отладка самой студии)
Я когда импортер для SMD пытался делать, отлаживал через Debugger.Break(), и подхватывал другим инстансом студии.
Но это было с 3.1 и в VS2008, в 2010 с xna 4.0. оно намертво вешает студию почему то.
Есть ещё такое http://badcorporatelogo.wordpress.com/2010/10/31/xna-content-pipe… ebugging-4-0/,
но у меня ещё руки не дошли глянуть(

наконец то ещё одна статейка появилась после полугодового затишья...

много времени кушает компил.. к сожелению.... с другой стороны код красивше =) и да порядок элементов.. помню намаялся :) а так удобная вещь!!

Пару лет назад, когда делал очередную итерацию своего двига, решил сделать такую систему, так как хотел отказаться от внешних библиотек импорта текстур и звуков. В итоге прироста загрузки не получил. Может, конечно, не так делал, но хранение в том виде, что и в памяти занимало у меня больше места и грузилось дольше. JPEG развернуть в памяти было быстрее, чем тупо скопировать BMP с харда... то же самое было с WAV.

[Tarantul]
> много времени кушает компил..
Да, это тоже проблема. У нас на проекте билд контента доходит до 10 минут. А это только текстуры и модельки. Я представляю, что будет, когда начнем билдить всякие хитрые ассеты, типа ландшафта.

Pipeline'ном пользуюсь только для работы с эффектами и шрифтами или в приложениях под телефон.
в виндовых приложениях текстуры и модели подгружаю своим менеджером.
т.к. например динамически подгружаемый через ContentManager текстурный контент удаляется из
памяти только с удалением самого экземпляра ContentManager. мне так проще и я контролирую весь процесс.