netlib.narod.ru< Назад | Оглавление | Далее >

Замечания об XNA

В завершение этой главы хочу привести несколько трюков и советов, относящихся к XNA Framework и XNA Game Studio Express. Как уже говорилось, можно просто начать кодировать, и все будет замечательно работать, но все же лучше иметь несколько закладок в браузере, куда можно обратиться при встрече с проблемами, или когда не знаешь, как решить тот или иной вопрос. Кроме того, в данном разделе обсуждаются преимущества .NET и C#, а также рассматриваются различия между XNA и DirectX для управляемого кода.

Важные ссылки

Вот несколько ссылок для ваших закладок:

Подходит ли C# для разработки игр?

На сайтах, подобных www.GameDev.net, постоянно есть ветки форумов, где обсуждаются различия между С++ и С#. Обычно после нескольких сообщений они превращаются в бессмысленную войну языков. В ранние дни .NET (2002 год) я часто участвовал в таких обсуждениях, но это было угнетающее занятие, поскольку 99.9% программистов были на стороне С++ и не было никакого способа убедить их, поскольку они даже не воспринимали вас всерьез. Языковая война почти не затрагивала C# как язык программирования, за исключением некоторого дурного вкуса из-за того, что Java провалилась в качестве платформы разработки игр (не считая мобильных телефонов), а C#, как и Java, является управляемым языком, и они выглядят очень похоже. Если подумать, такие же войны возникали когда С заменял ассемблер и когда С++ пришел на смену С. Даже сегодня, когда прошло более 20 лет с момента создания С++ Бъерном Страуструпом, некоторые программисты игр продолжают использовать С и не пользуются всеми преимуществами С++. Если вы взглянете на исходный код движков популярных игр, таких как Quake и Half Life, то увидите, что он больше похож на С, чем на С++.

Это действительно странная черта мира программирования игр; каждый боится уменьшения производительности при переходе на новый язык, а также боится потерять созданную базу кода или потратить слишком много времени на ее переработку для нового языка. Однако программисты игр быстро принимают новые техники и скриптовые языки, и находятся на переднем фронте разработки новых аппаратных средств. За год до того, как стали доступны первые видеокарты с поддержкой шейдеров версии 4.0, разработчики игр получили Direct3D 10, и многие начали работать с ним, даже не имея аппаратуры для запуска приложений.

Я быстро приспособился к .NET и C# в начале 2002 года, после того, как поработал с несколькими бета-версиями в 2001 году. Я только начал новый графический движок, и у нашей команды был проект, который мы хотели сделать. В ранние годы .NET не было никаких графических движков или чего-нибудь подобного, кроме простых двухмерных игр. Использовать DirectX или OpenGL непосредственно из C# было очень трудно. Требовалось много вызовов неуправляемых библиотек и привлечения указателей с трудноразрешимой логикой, которые были доступны только в небезопасном режиме C#. В 2003 году Microsoft выпустила первую версию DirectX для управляемого кода, что резко упростило разработку DirectX-приложений в .NET. Использование DirectX для управляемого кода вместо родных библиотек DirectX приводило к возрастанию нагрузки на 1 или 2 процента, что, если вдуматься, не так уж и важно (пусть у центрального процессора будет чуть больше работы, ведь большинство игр все равно более зависимы от видеокарты).

Однако, это не значило, что разработчики игр стали переходить на C#, они оставались скептически настроенными даже после того, как я в 2004 году выпустил первую коммерческую игру Arena Wars под .NET, и потребовался еще год, чтобы все больше разработчиков рискнуло дать .NET еще один шанс. Студенты и новички оценили простоту C#, и все больше людей начинает разработку игр в .NET. Дискуссии на тему «С++ против С#» никуда не делись, и точки зрения спорящих остались те же самые, но результат теперь получается более сбалансированный. (Я давно прекратил читать ветки форумов, в названии которых есть слово «против»; тратишь массу времени читая одни и те же аргументы.)

Всегда помните об этом, сталкиваясь с парнями, которые говорят, что С++ круче, а С# — только для новичков. Несколько лет назад то же самое говорили об ассемблере и C++, а в будущем появятся новые языки, делающие жизнь еще проще, и также будут люди не решающиеся принять их сразу. Большинство больших игровых студий также не могут сразу перейти к новым технологиям; они могут находиться в середине работы над большим проектом, или у них может быть большая база кода, которую сложно перенести. Но, в конечном счете, код будет перенесен и мы перейдем на следующую ступеньку лестницы языков высокого уровня.

На рис 1.15 приведена старая иллюстрация, где я показываю различия между DirectX в С++ и DirectX для управляемого кода (Managed DirectX, или MDX) в C#. Как видите, код MDX в два раза короче. Для XNA код будет еще короче, а загрузка текстур и отображение их на экране гораздо проще, но сравнивать XNA и MDX сложнее из-за различия концепций.


Рис. 1.15

Рис. 1.15


Привыкаем к конвейеру содержимого

Как вы видели при создании первого XNA-проекта, очень легко перетащить текстуру внутрь вашего проекта в XNA Studio. Хотя очень хорошо иметь все содержимое игры в одном месте непосредственно рядом с кодом, следует помнить пару вещей. В большинстве проектов, которые я видел в своей жизни, не помещали текстуры, модели и шейдеры непосредственно в проект Visual Studio. Причина в том, что гораздо проще скопировать несколько файлов и затем позволить игре загружать их непосредственно. Кроме того, по умолчанию Visual Studio не копирует файлы содержимого в выходной каталог; вам необходимо изменить Build Action с None на Content и установить для параметра Copy to Output Directory значение Copy if newer. Это настоящее преткновение, и XNA делает это гораздо проще.

Вы можете спросить, зачем менять принятый ранее способ загрузки текстур. Если вы собираетесь запускать ваши игры только на платформе Windows, можно по прежнему загружать текстуры и шейдеры динамически, не импортируя их в ваш проект как файлы содержимого XNA. Это позволит менять текстуры и шейдеры во время работы игры (конвейер содержимого XNA такую возможность не поддерживает). Однако, для файлов моделей это не работает, поскольку единственным методом загрузки для них является использование класса ContentManager, который поддерживает загрузку только из скомпилированных файлов содержимого .xnb.

На Xbox 360 можно загружать только файлы содержимого; прямая загрузка текстур или шейдеров не поддерживается. Если вы используете прямую загрузку текстур или шейдеров, убедитесь, что исключили поддержку платформы Xbox 360; библиотеки для Xbox могут загружать данные только из файлов содержимого.

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

Различия с MDX

Если вы знакомы с MDX (DirectX для управляемого кода) и хотите перенести ваши игры на XNA Framework, то на официальной странице XNA по адресу http://msdn.microsoft.com/directx/xna/migration/ есть замечательное руководство.

Дополнительную помощь вы найдете в документации XNA. Я не буду повторять здесь все, но главное — помнить о том, что XNA по умолчанию использует правосторонние матрицы, а MDX — левосторонние. Есть несколько новых классов и структур, устраняющих необходимость использования пространства имен Windows.Forms. Поскольку фиксированный конвейер функций не поддерживается, старый стиль работы с Windows Forms и забота о поддержку устаревших конфигураций PC больше не требуется. Графику и шейдеры мы обсудим во второй части книги.

Дополнительные утилиты и советы

Вы можете взглянуть на раздел Getting Gtarted в документации XNA, доступной из XNA Studio при выборе пункта Contents из меню Help, а затем выборе в содержании пункта XNA Game Studio Express. Там вы найдете информацию о подключении к вашей Xbox 360, о написании первого проекта и обо всех доступных наборах для начинающих.

Как я упоминал ранее, TestDriven.NET — это замечательный и инструмент для Visual Studio, а управляемая тестированием разработка является важной методологией для этой книги (см. главу 3). Еще одна замечательная утилита для разработчика .NET — Ants Profiler. В отличие от других инструментов, которые я упоминал до сих пор, этот не является бесплатным, но есть альтернативные варианты, которые могут помочь вам. Ants Profiler может показать, сколько времени занимает выполнение каждой строки вашего кода. Мне кажется, что это более полезно, чем использование высокоуровневых утилит профилировки, таких как NvPerf от NVidia, PIX из DirectX SDK или счетчиков производительности из Windows. Вы можете быстро выяснить почему фрагменты вашего кода визуализации работают медленно, обнаружить ошибки, вызывающие медленные методы слишком часто, и просмотреть ваш код, получая новую интересную информацию о нем.

Если вам надо больше ссылок на сайты в Интернете, обратитесь к замечательной коллекции ссылок по XNA http://xnadevelopment.com/links.shtml.

Есть много сайтов, посвященных XNA, и почти каждый день появляется еще несколько сообществ и ресурсов. Воспользуйтесь поиском Google, чтобы определить, какие из них наиболее популярны.


netlib.narod.ru< Назад | Оглавление | Далее >

Сайт управляется системой uCoz