Извините, ничего не найдено.

johnk · 02.03.2012, 22:36

Приветствую всех жителей и гостей этого замечательного ресурса.

Позвольте начать свою авторскую серию статей и уроков по теме разработки игр на C#. Я изначально предполагаю, что с языком вы знакомы. Рассматривать мы будем DirectX. От вас потребуется внимание, желание, а также следование принципу «доверяй, но проверяй».

Итак, поехали.
————————————————————————————————————

Введение

Для начала небольшая вводная про C# и .NET. Как известно, этот язык стал в некоем смысле «козырем» новой платформы от Microsoft. Язык статически типизирован[1], реализует все принципы ООП, и если честно, со временем вызывает ООП головного мозга. Вся работа языка основана на инфраструктуре, которую предоставляет .NET. Соответственно, язык попросту не существует без .NET, как и в некотором смысле .NET не существует без C#.

Язык, который «завязан» на платформе .NET и без нее не существует, называется управляемым (от англ. managed) языком. По аналогии, программа, написанная на управляемом языке, называется управляемой программой.

Инфраструктура .NET это:

Среда исполнения[2] — виртуальная машина, благодаря которой работают все (без исключения) приложения, написанные на управляемом языке
Библиотека классов[3] — стандартная библиотека, которая доступна любому управляемому языку

Не смотря на то, что в выполнении приложения участвует виртуальная машина, язык C# (как и любой другой на этой платформе, но в дальнейшем пойдет речь только о C#) не совсем интерпретируемый[4].

Когда на ресурсе gamedev.ru возникают споры о языке и платформе в частности, некоторые одиозные личности утверждают, что такой подход ставит «нет» на использовании языка в сферах, где требуется высокая производительность. Очевидно, что такие люди просто не в курсе, как работает исполняемая среда. В любом случае, так однозначно утверждать про производительность нельзя. Давайте разберемся, почему.

Действительно, ваш код, в процессе компиляции, переводится в промежуточный, так называемый IL-код. Затем этот код интерпретируется исполняющей средой. В этом смысле любой управляемый язык считается интерпретируемым. Но что именно происходит во время интерпретации кода? Промежуточный код, который является платформонезависимым, превращается в платформозависимые машинные инструкции[5].

Соответственно, скорость работы приложения напрямую зависит от того, как эффективно работает механизм перевода IL-кода в инструкции. Этим, в инфраструктуре .NET, занимается так называемый JIT-компилятор. В момент исполнения приложения, среде исполнения (пардон за тавтологию) известно, какая конфигурация у компьютера. Среда исполнения знает, какой установлен процессор, сколько оперативной памяти на целевой машине, а также некоторую другую информацию. По сути, это и есть так называемая «киллер-фича» .NET, благодаря которой JIT-компилятор может одержать победу над сгенерированным машинным кодом какого-нибудь компилятора к компилируемому языку* (ха, снова тавтология!).

Но...

Вот уже прошло 10 лет (первая версия .NET вышла в 2002-ом году), а мнение насчет низкой производительности все еще присутствует в сознании людей. И неспроста. Компания-миллиардер, которая воротит миллионами, так и не смогла найти адекватных людей, которые написали бы вменяемый компилятор. В сети можно найти тесты, где, по сути, сравнивается работа JIT-компилятора и других. Правда не спутайте с тестами, где так же учитывается работа с памятью. Я приведу самый вопиющий случай: сравнение JIT-компилятора и студийного, от Microsoft. Здесь демонстрируется, как детище Microsoft (я про компилятор для C++

) рвет еще одно детище того же Microsoft, JIT-компилятор.

Особую боль в районе пятой точки вызывает тест, где компилятор для C++, не используя SSE[6], рвет JIT-компилятор, который на целевом процессоре, наверняка, использовал SIMD-инструкции[7]. То есть, заранее зная, что там-то и там-то можно сгенерировать сверхоптимальный, заточенный под конкретный процессор, код, JIT-компилятор либо этого не сделал вовсе, либо сделал это не правильно. В такие моменты очень трудно оторвать ладонь от лица, но надо. Поскольку отставание не велико, а слово «рвет» я использовал для провокации

Здесь можно разводить бесконечный спор, приводя аргументы как за JIT-компилятор, так и за его оппонентов, но суть одна: JIT-компилятор, не смотря на преимущества, всегда генерирует унифицированный код, хоть и под конкретный процессор. Как это понимать? Дело в том, что он не всегда понимает, что от него требуется. Такое бывает и там, на стороне компилируемых языков. Но «там», в случае, если вы видите, что сгенерированный код неоптимален, вы имеете возможности для оптимизации. Возможности разные, вплоть до того, что вы явно можете описать, какие машинные инструкции выполнять в каждом конкретном месте.

Такие возможности в самом .NET отсутствуют, поскольку идеология не позволяет. Но такое все-таки отчасти возможно, например, в Mono[8] (это свободная реализация .NET) можно использовать SIMD[9][10]. Короче говоря, отдавая полномочия среде исполнения, вы в некоторой степени теряете возможность контролировать происходящее.

Правда в C# есть малюсенькая лазейка, позволяющая спасти производительность в узкоспециализированных местах. Там присутствует так называемый unsafe-контекст, который позволяет вытворять небезопасные (с точки зрения идеологии .NET) вещи: использовать указатели. Обращение к элементу массива по указателю, например, позволяет избежать проверки на выход за пределы массива. На такой мелочи в общем итоге можно сэкономить значительное количество тактов процессора. Но в том же C++, доступ к элементам массива всегда осуществляется по указателю, без проверок. (Лень было вставлять троллфейс второй раз).

Оптимизация в .NET это штука мелочная, порой напоминающая сплошные извращения. И я еще не затрагивал тему сборки мусора. Не затрагивал…и не затрону, а то совсем запугаю новичков, которые хотят делать игры на управляемом языке. Главное, сделать один вывод: производительность .NET вещь неоднозначная, иногда она может быть не хуже, чем производительность приложения, написанного на компилируемом языке. Эта тема крайне сложная, синтетические тесты здесь не всегда объективны, но позволяют увидеть основную тенденцию: JIT-компилятор еще далек от идеала.

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

Отвечая на вопрос, а стоит ли использовать .NET, я обычно говорю следующее: «Выбирая .NET, вы теряете производительность. Выбирая .NET, вы получаете производительность».

И здесь нет опечатки, просто производительность разных порядков. Если в первом случае идет речь о производительности самого приложения, то во втором о вашей собственной. Дело в том, что синтаксически, C# гораздо чище и проще C++, а код на нем иногда получается короче, чем аналогичный на C++. А если взять в расчет еще и удобство среды разработки, в которой приходится работать, то начинаешь задумываться, а что лучше использовать: C# или C++? Как бы там ни было, я здесь буду писать для тех, кто свой выбор сделал в пользу первого.

Итак, есть .NET, есть знание C#, есть желание делать игры. С чего начать? Я познакомился с программированием году в 2003-ем, когда в моем городе практически не было нормального доступа к Интернет. В наличии были лишь диал-ап модемы и, следовательно, диал-ап-интернет. В эти времена и речи не шло о скачивании каких-нибудь там видеоуроков, крутых движков (а их, собственно, в открытом доступе и не было) и тому подобному. В наличии были лишь легковесные решения, типа Blitz3D, DarkBasic, PureBasic. Тогда, все вопросы решались самостоятельно (форумы тоже были актуальны, но как по мне, рассматриваемые вопросы были в разы интереснее и сложнее), а книги — во-первых, покупались, во-вторых — изучались. Скажу честно, было круто!

Теперь же все резко поменялось: книжки покупать больше не надо, количество книг по разной тематике зашкаливает за все мыслимые и немыслимые пределы. Но кто их читает? Пройдешься по форумам в сети, видишь, что там, в основном, задаются вопросы, которые освещены на каждом программерском сайте, описаны в каждой книге по языку программирования. Новое поколение либо на самом деле какое-то несостоятельное (в смысле, шагу сделать без наставлений не могут), либо притворяются. Информация, которая буквально валяется под ногами, почему-то игнорируется. С движками тоже все круто поменялось: как сейчас помню актуальность шуток, когда новичку предлагалось игру писать не с нуля, а воспользоваться крутым движком типа Unreal Engine. (Молодым бойцам на заметку: раньше достать движок было невозможно, только лицензируя. Сейчас же — любой желающий может делать на нем игры). Апофеозом нынешнего поколения для меня стало одно открытие. В последний мой визит в книжный магазин, я заметил шедевр, несущий название «Как найти работу?». Книга эта, на глаз, страниц на 150-200, и я просто не представляю, что там внутри. Видимо из-за того, что классическая схема «составил резюме → разослал в интересующие компании → прошел собеседование» не работает, там, по всей видимости, представлены секретные техники минета и прочие прелести обольщения для девушек, чтобы успешно пройти собеседование.

Поэтому, возвращаясь к вопросу, даю элементарный ответ: начать разработку игр надо с разработки игр. Не с поглощения тонн книг по программированию, математике, физике, игровому дизайну, по графике в целом; не с написания универсального движка, который не понятно для кого создается, и непонятно где будет использоваться, а с разработки игр. И в этой тавтологии заключен «сакральный» смысл. Ваша цель — это создание игры. Задумайтесь, бесконечное поглощение книг, которые якобы могут пригодиться, двигает вас к цели? А написание движка, который якобы потом будет использоваться для создания игры, опять-таки, двигает ли вас к цели, то есть к созданию игры? В обоих случаях ответ отрицательный. Никто не спорит, что для создания игры потребуются определенные знания. Но знания эти фундаментальные, и скорее всего, ими вы уже и так обладаете. Единственная проблема здесь в знании языка, который вы будете использовать. Здесь действительно не обойтись без литературы. Дальше, можно подсматривать в поисковике, или самому предлагать решения. Движок без игры — пустая трата времени, он ничего не стоит. Но если вы будете писать игру, параллельно «вырисовывая» что-то на подобии фреймворка, из этого может получиться что-то безумно удобное, по крайней мере, для вас лично.

Главный принцип, который, как мне кажется, нужно практиковать — делать только то, что необходимо и всегда применять комплексный подход. То есть, нет смысла зацикливаться на какой-то одной составляющей, если она и так неплохо работает, есть смысл делать то, что игре сейчас действительно не хватает. Игра должна быть «играбельной» с первых дней разработки. В случае с C#, этого можно добиться уже в первые часы разработки. Здесь уместно вспомнить и о такой замечательной проблеме новичков (и не только), как стремление к идеальной архитектуре. Самый оптимальный ответ на данном этапе звучит примерно так: идеальная архитектура — это химера, мираж. То, что идеально для одного, может показаться элементарным говнокодом для другого. Вообще, правильная архитектура — это опыт. Так что на первых порах на нее необходимо забить. Полностью. В следующих статьях я представлю достаточно эффективную технику написания программ, которую можно использовать в случае, если испытываете неуверенность в процессе написания кода и постоянно ловите себя на стремлении к идеальной архитектуре. Стремление это бесплодное, вам все равно не удастся все заранее идеально спланировать. Особенно когда вы еще никогда не писали игр.

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

Резюме

Язык, который работает исключительно при наличии инфраструктуры .NET, называется управляемым
C# — это управляемый язык, со статической типизацией, реализующий принципы объектно-ориентированного программирования
Написанный на C# код, в процессе компиляции превращается в платформонезависимый промежуточный код, а в процессе исполнения — в платформозависимые машинные инструкции
О производительности управляемых приложений нельзя говорить однозначно и категорично
Начинать разработку игр надо с создания игр
Не с создания универсальных движков, а с написания игр
Не с прочтения гор литературы, а с разработки игр
Создаваемая игра должна быть «играбельной» с первых дней разработки
Идеальная архитектура приложения — это опыт
В начале своего пути, не тратьте свои силы на раздумья об идеальной архитектуре, а делайте то, чего игре в данный момент не хватает

Ссылки

Сноски
*я использую термин «компилируемый язык» чтобы избежать использования англосаксонского «нэйтив» (от англ. native)

johnk · 02.03.2012, 22:39

Обсуждение ведем здесь: http://forum.boolean.name/showthread.php?t=16429