Каковы типичные ловушки при написании игр с управляемым языком, например C #? [закрыто]

Какие проблемы вы столкнулись при написании игр для ПК с управляемым языком, например C #, и как вы их разрешили?

65 голосов | спросил Michael Barth 14 J000000Wednesday10 2010, 23:17:14

7 ответов


69

Я не знаю много о java, так что это с точки зрения .net dev.

Самый большой из них - мусор. сборщик мусора .net на окнах делает фантастическую работу, и вы можете уйти без малыша, сидящего по большей части. На xbox /winPhone7 это другое дело. Если вы получаете киоски каждые несколько кадров, сбор мусора может вызвать проблемы. В настоящий момент он запускается после каждого распределения в 1 МБ.

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

  • Нарисуйте содержимое GC.GetTotalMemory () на экране. Это дает вам приблизительное количество выделенных байт, используемых вашей игрой. Если он вряд ли движется, у вас все в порядке. Если это происходит быстро, у вас есть проблемы.
  • попытайтесь выделить все ваши объекты heap спереди. Если вы не распределите все до начала игры, каждый раз, когда вы нажмете мега распределения, ваш выход в режим ожидания. Нет ассигнований, нет коллекций. Так просто.
  • После загрузки вызовите GC.Collect (). Если вы знаете, что большинство ваших больших ассигнований не соответствует действительности, приятно знать, что система знает.
  • НЕ ВЫЗЫВАЙТЕ GC.Collect () каждый кадр. Это может показаться хорошей идеей, держась поверх вашего мусора и всего этого, но помните, что только хуже, чем сбор мусора - сбор мусора.
  • Посмотрите, откуда идет ваш мусор. Существуют некоторые распространенные причины, такие как объединение строк вместо использования StringBuilder (остерегайтесь, StringBuilder ) не является волшебной пулей и может все еще вызывать распределения! Это означает, что простые операции, такие как добавление числа в конец строки, могут создавать удивительные количества мусора) или используя foreach петли над наборами, которые используют интерфейс IEnumerable , также могут создавать мусор, если вы не знаете (например, foreach (ЭффектPass Pass Effect. CurrentTechnique.Passes) является общим)
  • Используйте такие инструменты, как профайлер памяти CLR выяснить, где выделяется память. Существует множество учебных пособий о том, как использовать этот инструмент.
  • Когда вы знаете, где вы выделяете во время игрового процесса, посмотрите, можете ли вы использовать трюки, такие как объединение объектов, чтобы уменьшить этот счет.
  • Если все остальное не удается, заставьте ваши коллекции работать быстрее! GC на компактном каркасе следует каждой ссылке в вашем коде, чтобы выяснить, какие объекты больше не используются. Рефакторинг вашего кода использует меньше ссылок!
  • Не забудьте использовать IDisposable для классов, содержащих неуправляемые ресурсы. Вы можете использовать их для очистки памяти, которую GC не может освободить.

Другая вещь, о которой стоит подумать, - это производительность с плавающей запятой. Несмотря на то, что .Net JITer выполняет достаточную оптимизацию по конкретным процессорам, он не может использовать SSE или любые другие наборы инструкций SIMD для ускорения математических вычислений с плавающей запятой. Это может привести к большой разнице в скорости между C ++ и C # для игр. Если вы используете моно, у них есть специальные библиотеки SIMD, которые вы можете использовать.

ответил Cubed2D 15 J000000Thursday10 2010, 00:52:06
10

Типичная ошибка производительности не рассматривает сборщик мусора при разработке /разработке игры. Производство слишком большого количества мусора может привести к «икотам» в игре, которые происходят, когда GC работает в течение значительного длительного времени.

Для C # использование объектов значений и выражение «using» могут облегчить давление из GC.

ответил Matias Valdenegro 15 J000000Thursday10 2010, 00:45:36
9

Я бы сказал, что самые большие проблемы, с которыми я столкнулся при написании игр на C #, - отсутствие достойных библиотек. Большинство из них были либо прямыми портами, либо неполными, либо обертки над библиотекой C ++, которые повлекли за собой серьезное снижение производительности для маршалинга. (Я говорю конкретно о MOgre и Axiom для библиотеки OGRE и BulletSharp для библиотеки физики Bullet)

Управляемые языки (в отличие от Interpreted - ни Java, ни C #, на самом деле не интерпретируются) могут быть столь же быстрыми, как и родные языки, если вы хорошо понимаете, что на самом деле заставляет их замедлить работу (маршалинг, сбор мусора). Реальная проблема, я думаю, в том, что разработчики библиотеки еще этого не осознали.

ответил Karantza 14 J000000Wednesday10 2010, 23:39:35
8

Как и другие, GC-паузы - самая большая проблема. Использование пулов объектов является одним из типичных решений.

ответил munificent 15 J000000Thursday10 2010, 00:54:45
4

C # и Java не интерпретируются. Они компилируются в промежуточный байт-код, который после JIT становится таким же быстрым, как и собственный код (или достаточно близко, чтобы быть незначительным)

Самая большая ошибка, которую я обнаружил, заключается в освобождении ресурсов, которые напрямую влияют на пользовательский интерфейс. Эти языки автоматически не поддерживают детерминированную финализацию , как это делает C ++, что, если вы не ожидая, что это может привести к тому, что вещи, подобные сетке, плавающие вокруг сцены после того, как вы подумали, что они были уничтожены. (C # выполняет детерминированное завершение с помощью IDisposable , я не уверен, что делает Java.)

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

ответил Sean Edwards 14 J000000Wednesday10 2010, 23:51:15
4

Ни Java, ни C # не интерпретируются. Оба они скомпилированы в собственный машинный код.

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

ответил gman 14 J000000Wednesday10 2010, 23:53:18
2

Одна большая ошибка, которую я вижу в играх с такими языками (или с помощью таких инструментов, как XNA, TorqueX engine и т. д.), заключается в том, что вам будет трудно найти команду хороших людей, обладающих опытом, необходимым для создания эквивалента для чего было бы легко найти людей на C ++ и OpenGL /DirectX.

Индустрия игр dev по-прежнему очень сильно погружена в C ++, поскольку большинство инструментов и конвейеров, которые используются для выталкивания больших или просто хорошо отполированных небольших игр, были написаны на C ++, и насколько я знаю ВСЕ официального разработчика наборы, которые вы можете получить для XBox, PS3 и Wii, выпущены только с совместимостью для C ++ (теперь инструментарий XBox может быть более управляемым, кто-нибудь знает больше?)

Если вы хотите разрабатывать игры для консолей прямо сейчас, вы в значительной степени получаете XNA и C # на XBox, а затем только в боковой части игровой библиотеки под названием XBox Live Indie Games. Некоторые, кто выигрывает конкурсы и т. Д., Выбирают, чтобы довести свою игру до реальной XBox Live Arcade. Помимо этого плана по созданию игры для ПК.

ответил mikeschuld 15 J000000Thursday10 2010, 21:18:38

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132