XNA і C # проти 360-х в порядку процесора

Прочитавши цю сказу , я відчуваю, що вони, мабуть, праві (бачачи, що Xenon і CELL BE обидва чутливі до коду невідомого відгалуження та кешу ), але я чув, що люди чудово налаштовують ігри з C #.

Отже, чи правда, що робити XNA неможливо нічого професійного , або в плакаті просто не вистачало того, що робить XNA вбивчим API для розвитку ігор?

Під професіоналом я не маю на увазі в тому сенсі, що можна заробити на цьому гроші, але більше в тому сенсі, що більш професійними іграми є моделі фізики та анімаційні системи, які здаються поза досяжністю мови з такими певними перешкодами для внутрішньої роботи . Якщо я хотів написати систему зіткнень або двигун динаміки рідини для своєї гри, я не відчуваю, що C # пропонує мені можливість зробити це, як генератор коду виконання, і відсутність властивостей перешкоджає продуктивності.

Однак багатьом людям здається, що вони добре працюють у цих обмеженнях, роблячи свої успішні ігри, але, здавалося б, уникаючи будь-якої проблеми упущенням. Я не помічав, щоб будь-які ігри XNA робили щось складне, крім того, що вже надано бібліотеками, або обробляються шейдерами. Це уникнення складнішої ігрової динаміки через обмеження C # або просто люди, зосереджені на тому, щоб це зробити ?

Чесно кажучи, я не можу повірити, що AI війна може підтримувати багато підрозділів AI без певного підходу, орієнтованого на дані, або деяких брудних C хаків, щоб зробити його краще, ніж стандартний підхід, і, мабуть, це частково і моє питання, як люди зламали C #, щоб він міг робити те, що кодери гри природно роблять із C ++?

Гаразд, просто тріпати дірки в тій розправці, яку ви пов’язали:

• "C # покладається на інтерпретатора" Just In Time " - неправильно - це компілятор JIT . Після того, як метод буде JITted один раз , складений код повторно використовується для кожного виклику. Скомпільований код дуже близький настільки ж швидко, як і рідний, попередньо складений код.
• "Процесор Xenon - це" на місці "процесор - він означає" по порядку "? - І: "Процесор Xenon не має передбачення галузей" . Це означає, що компіляція JIT, природно, призводить до поганого коду, який повинен бути переупорядкований процесором і викликає багато розгалужень - що є абсолютною нісенітницею . Однакові поради щодо продуктивності роботи цієї архітектури процесора стосуються як C ++, так і C #.
• "[JIT] вимагає постійної прошивки на 360" - неправильно, складений код може зберігатися в кеші, як і будь-який звичайно складений код. (Якщо він означає промивання трубопроводу, див. Вищевказаний пункт.)
• "generics [...] використання генерації коду" - generics JITted, як і все інше, і, як і все інше, JITted код швидко. Не застосовується штраф за ефективність використання дженериків.
• "всі сексуальні шматочки мови [...] вимагають передбачити будь-яку галузь ..." - як це не стосується і C ++? - "... або [...] на місці генерації коду" - він має на увазі JITting? Я згадав, що це швидко? (Я не буду входити в усі місця, де CLR на робочому столі використовує фактичне генерування коду - функцію, яку не підтримує Xbox 360!)
• "[C # не має] масових бібліотек [C ++]" - хіба, скажімо, сама XNA? І ще багато . (Все-таки це дещо справедливий момент.)

XNA на Xbox 360 працює на зміненій версії .NET Compact Framework CLR. Я не сумніваюся, що це не відповідає стандарту настільної версії. JITter, ймовірно , не такий хороший - але я також не думаю, що це погано . Я здивований, що він не згадав про сміттєзбірник, який жахливий порівняно з CLR на робочому столі.

(Зрозуміло - у будь - якому випадку ви не повинні бити сміттєзбірника у професійно розробленій грі , так само як ви повинні бути обережними з розподілами у будь -якій грі професійного класу.)

(Для фактичного технічного обговорення .NET Compact Framework, можливо, почніть з цієї серії статей: Огляд , JIT Compiler , а також GC та купа .)

Те, що він абсолютно не визначений щодо своєї термінології, ускладнює навіть розуміння того, що він має на увазі. Або він перебуває в режимі максимальної рентабельності, або не знає, про що йде мова.

Тепер, коли ми отримали , що з шляху, ось деякі речі , які ви б пропустити за допомогою XNA на 360, а не йти рідним :

• Доступ до модуля SIMD / Vector для дійсно, дуже швидкої математики з плаваючою точкою процесора
• Можливість використання коду рідної мови, який, мабуть, буде трохи швидшим, ніж C #
• Можливість бути трохи трохи повільнішою з тим, як ви виділяєте пам'ять
• Ігри XBLIG мають доступ лише до 4 з 6 ядер (але ми все ще отримуємо всі 3 процесора, і вони теж не повноцінні ядра, тому ми не пропускаємо багато) - не впевнений, чи стосується це не XBLIG XNA ігри
• Повний DirectX доступ для виконання дійсно неясних графічних хитрощів

Варто також зазначити, що це лише обмеження на стороні процесора. У вас все ще є абсолютно безкоштовний доступ, що працює на GPU.

Я описав ці речі в цій відповіді на те, що фактично те саме питання, що і це. Як я вже згадував у цій відповіді, XNA абсолютно підходить для "професійного" розвитку .

Єдині причини, яких ви уникаєте, - це те, що ви не можете найняти талант C #, ліцензувати двигуни C # та використовувати повторно існуючий код C # так, як ви можете з наявною базою знань C ++. Або тому, що ви також можете орієнтуватися на платформу, яка не підтримує C #.

Звичайно, для багатьох з нас, хто не є "професійними" розробниками, XNA - наш єдиний варіант потрапити на Xbox 360, що робить суперечку.

Щоб відповісти на ваші інші запитання:

Ніщо в C # не заважає використовувати підходи, орієнтовані на дані, фактично так само, як ви використовували їх у C ++.

У C # бракує можливості автоматично вбудовувати код під час компіляції, і (не виходячи з перевірки) я впевнений, що компактний JITter компактного CLR не може вбудувати методи (CLR на робочому столі може). Отже, для критично важливих показників коду, можливо, доведеться вручну вбудовувати його в C #, де C ++ надає певну допомогу.

Можливо, більша причина, чому ви часто не бачите в процесах, що займають математику процесора, таких як виявлення зіткнень та моделювання рідини в C #, це відсутність доступу до векторного блоку (як згадувалося вище).

Вам доведеться визначити "професійний". Чи можете ви зробити злих птахів, рослини проти зомбі тощо? Абсолютно. Не могли б ви зробити Crysis 2, COD, Halo? Я сумніваюся в цьому. Використання C # дійсно впливає на ігри, які дуже інтенсивно працюють на процесорі, а також потрібно вичавити кожен останній байт пам'яті (ви втрачаєте сміття), тому ви можете зробити ще дуже багато.

Як інструмент для навчання людей, що розпочали роботу, інструмент для складання прототипів, платформа для написання ігор, яка може боротися з торгівлею тощо. Він фантастичний і має багато потужності та простоти, він просто не призначений для того, щоб робити те, що вам потрібно викликати ігри "AAA". Це також забирає багато болю і страждань, з якими люди повинні переживати при перенесенні між собою платформ та сумісності.

Якщо ви придумали дивовижну гру, і ви зіткнетесь з обмеженнями того, що ви можете зробити з XNA, то я б запропонував зв’язатися безпосередньо з MS, якщо ідея дійсно досить хороша, вони можуть просто дати вам змогу отримати повний розвиток комплект.

Простий факт полягає в тому, що вам не потрібна велика кількість полігонів, повноцінне освітлення HDR або найцікавіша у світі фізика, щоб зробити цікаву гру, і якщо ваш ігровий план не містить жодної з них, то чому б не піти швидше час розробки?

більше професійних ігор мають моделі фізики та анімаційні системи

Це просто неправильно. Професійні ігри мають те, що потрібно, щоб реалізувати свій ігровий процес і досягти свого художнього вигляду, і нічого, і справді, не менш. Гра не є більш професійною, тому що вона виглядає більш реалістично або має більш детальну фізику. Гра, яка професійно досягає, - це ігрові та візуальні цілі, вчасно, на бюджет тощо, і доставляє прибуток.