XNA und C # gegen die 360 ​​im Auftragsprozessor

Nachdem ich diesen Artikel gelesen habe , habe ich das Gefühl, dass sie wahrscheinlich Recht haben (da Xenon und CELL BE sehr empfindlich gegenüber verzweigtem und Cache-ignorantem Code sind ), aber ich habe gehört, dass die Leute Spiele auch mit C # gut machen.

Stimmt es also, dass man mit XNA nichts professionelles machen kann ? Oder hat das Poster einfach gefehlt, was XNA zur Killer-API für die Spieleentwicklung macht?

Unter professionell verstehe ich nicht, dass man damit Geld verdienen kann, sondern vielmehr, dass die professionelleren Spiele über Phsyics-Modelle und Animationssysteme verfügen, die außerhalb der Reichweite einer Sprache mit solch eindeutigen Barrieren für das Wesentliche zu liegen scheinen . Wenn ich ein Kollisionssystem oder eine Fluiddynamik-Engine für mein Spiel schreiben wollte, habe ich nicht das Gefühl, dass C # mir die Möglichkeit bietet, dies zu tun, da der Laufzeitcode-Generator und das Fehlen von Intrinsics die Leistung beeinträchtigen.

Es scheint jedoch, dass viele Leute gut mit diesen Einschränkungen umgehen, ihre erfolgreichen Spiele machen, aber scheinbar jedes der Probleme durch Auslassen vermeiden. Ich habe nicht bemerkt, dass XNA-Spiele irgendetwas anderes komplexes machen als das, was bereits von den Bibliotheken bereitgestellt oder von Shadern gehandhabt wird. Ist dies die Vermeidung der komplexeren Spieldynamik aufgrund der Einschränkungen von C # , oder nur Leute, die sich darauf konzentrieren , es zu erledigen ?

Ehrlich gesagt kann ich nicht glauben, dass KI-Krieg so viele KI-Einheiten ohne einen datenorientierten Ansatz oder schmutzige C # -Hacks aufrechterhalten kann , damit es besser läuft als der Standardansatz, und ich denke, das ist zum Teil auch meine Frage, wie Haben die Leute C # gehackt, damit es das kann, was Spiele-Programmierer natürlich mit C ++ machen?

OK, nur um ein paar Löcher in das Geschwätz zu stecken, das du verlinkt hast:

• "C # ist auf einen" Just In Time "-Interpreter angewiesen - falsch - es ist ein JIT- Compiler . Nachdem eine Methode einmal JITted wurde , wird der kompilierte Code für jeden Aufruf erneut verwendet. Der kompilierte Code ist fast so schnell wie nativer, vorkompilierter Code.
• „Xenon CPU ist ein‚in place‘Prozessor“ - bedeutet er „in Ordnung“? - Und: "Xenon-CPU hat keine Verzweigungsvorhersage" . Er impliziert dies bedeutet, dass die JIT-Kompilierung auf natürliche Weise fehlerhaften Code erzeugt, der von der CPU neu angeordnet werden muss, und viel Verzweigung verursacht - was absoluter Unsinn ist . Die gleichen Leistungsempfehlungen für die Ausführung auf dieser CPU-Architektur gelten sowohl für C ++ als auch für C #.
• "[JIT] erfordert ständiges Spülen des 360" - falsch, der kompilierte Code kann wie jeder normal kompilierte Code im Cache gehalten werden. (Wenn er Rohrleitungsspülung meint, siehe den obigen Punkt.)
• "generics use code generation" - generics sind wie alles andere JITted und wie alles andere ist der JITted-Code schnell. Es gibt keine Leistungseinbußen für die Verwendung von Generika.
• "alle sexy sprachen erfordern eine [...] verzweigungsvorhersage ..." - wie trifft dies nicht auch auf c ++ zu? - "... oder [...] In-Place-Codegenerierung" - meint er JITting? Habe ich schon erwähnt, dass es schnell ist? (Ich werde nicht auf alle Bereiche eingehen , in denen die Desktop- CLR die eigentliche Codegenerierung verwendet - eine Funktion, die von der Xbox 360 nicht unterstützt wird!)
• "[C # hat] nicht die massiven Bibliotheken [von C ++]" - außer zum Beispiel XNA selbst? Und vieles mehr . (Trotzdem ist dies ein ziemlich fairer Punkt.)

XNA auf der Xbox 360 läuft auf einer modifizierten Version der .NET Compact Framework CLR. Ich habe keinen Zweifel, dass es nicht dem Standard der Desktop-Version entspricht. Der JITter ist wahrscheinlich nicht so gut - aber ich denke auch nicht, dass er schlecht ist . Ich bin überrascht, dass er den im Vergleich zur Desktop-CLR schrecklichen Müllsammler nicht erwähnt hat .

(Natürlich - Sie sollten in einem professionell entwickelten Spiel sowieso nicht auf den Müllsammler treffen , genauso wie Sie bei Zuweisungen in einem professionellen Spiel vorsichtig sein müssen .)

(Für eine aktuelle technische Diskussion des .NET Compact Framework beginnen Sie möglicherweise mit dieser Artikelserie: Overview , JIT Compiler , GC und Heap .)

Die Art und Weise, wie er in Bezug auf seine Terminologie völlig unspezifisch ist, erschwert es, überhaupt zu verstehen, was er meint. Entweder ist er im Maximalmodus oder er weiß nicht, wovon er spricht.

Jetzt, wo wir haben , dass aus dem Weg, hier einige Dinge, die Sie tun auf verpassen von XNA mit auf den 360, anstatt going native :

• Zugriff auf die SIMD / Vector-Einheit für wirklich schnelle CPU-Gleitkomma-Berechnungen
• Möglichkeit zur Verwendung von muttersprachlichem Code, der wahrscheinlich etwas schneller als C # sein wird
• Die Fähigkeit, ein bisschen zu sein etwas fauler mit , wie Sie Speicher zuweisen
• XBLIG-Spiele haben nur Zugriff auf 4 der 6 Kerne (aber wir haben immer noch alle 3 CPUs und sie sind auch nicht voll, so dass wir nicht viel verpassen) - nicht sicher, ob dies für Nicht-XBLIG-XNA gilt Spiele
• Voller DirectX-Zugriff für wirklich unübersichtliche grafische Tricks

Es ist auch erwähnenswert, dass dies nur CPU-seitige Einschränkungen sind. Sie haben immer noch freien Zugriff auf die GPU.

Ich habe diese Dinge in dieser Antwort auf die Frage beschrieben, die im Grunde genommen dieselbe ist wie diese. Wie ich in dieser Antwort erwähnt habe, ist XNA absolut für die "professionelle" Entwicklung geeignet .

Der einzige Grund, den Sie vermeiden sollten, besteht darin, dass Sie kein C # -Talent einstellen, C # -Module lizenzieren und vorhandenen C # -Code auf dieselbe Weise wiederverwenden können, wie Sie es mit der vorhandenen Basis von C ++ - Kenntnissen tun können. Oder weil Sie möglicherweise auch auf eine Plattform abzielen, die C # nicht unterstützt.

Für viele von uns, die keine "professionellen" Entwickler sind, ist XNA natürlich unsere einzige Option, um auf die Xbox 360 zuzugreifen.

Um Ihre anderen Fragen zu beantworten:

Nichts in C # hindert Sie daran, datenorientierte Ansätze genau so zu verwenden, wie Sie sie in C ++ verwenden würden.

C # ist nicht in der Lage, Code beim Kompilieren automatisch inline zu schreiben, und ich bin mir ziemlich sicher, dass der JITter der kompakten CLR keine Inline-Methoden kann (das kann die Desktop-CLR). Für leistungskritischen Code müssen Sie möglicherweise manuell in C # einbinden, wobei C ++ Unterstützung bietet.

Wahrscheinlich ist ein größerer Grund, warum Sie CPU-mathematikintensive Dinge wie Kollisionserkennung und Fluidsimulationen in C # nicht oft sehen, der fehlende Zugriff auf die Vektoreinheit (wie oben erwähnt).

Sie müssten "professionell" definieren. Könntest du Angry Birds, Plants vs Zombies usw. machen? Absolut. Könnten Sie Crysis 2, COD, Halo tun? Das bezweifle ich. Die Verwendung von C # wirkt sich nur auf Spiele aus, die sehr rechenintensiv sind und außerdem das letzte Byte des Arbeitsspeichers beanspruchen müssen (Sie verlieren an der Garbage Collection), sodass Sie immer noch eine Menge tun können.

Als Lerntool für Einsteiger, Prototyping-Tool, Plattform für das Schreiben von Spielen, die sich mit Kompromissen usw. auseinandersetzen können, ist es fantastisch und hat viel Kraft und Einfachheit Nennen Sie die "AAA" Spiele. Es beseitigt auch viele Schmerzen und Leiden, über die sich Menschen mit plattformübergreifender Portierung und Kompatibilität Sorgen machen müssen.

Wenn Sie sich ein fantastisches Spiel einfallen lassen und die Grenzen dessen, was Sie mit XNA tun können, kennen, dann würde ich vorschlagen, dass Sie sich direkt an MS wenden. Wenn die Idee wirklich gut genug ist, können Sie möglicherweise eine vollständige Entwicklung in die Hände bekommen kit.

Die einfache Tatsache ist, dass Sie keine hohe Polygonzahl, volle HDR-Beleuchtung oder die interessanteste Physik der Welt benötigen, um ein interessantes Spiel zu erstellen. Wenn Ihr Spielplan keines davon enthält, warum sollten Sie nicht ein schnelleres wählen? Entwicklungszeit Lösung?

professionellere Spiele haben Phsyics-Modelle und Animationssysteme

Das ist einfach falsch. Professionelle Spiele haben das, was sie brauchen, um ihr Gameplay umzusetzen und ihren künstlerischen Look zu erreichen, und nicht mehr und nicht weniger. Ein Spiel ist nicht professioneller, weil es realistischer aussieht oder eine detailliertere Physik aufweist. Ein professionelles Spiel erreicht sein Gameplay und seine visuellen Ziele, pünktlich, im Rahmen des Budgets usw. und verschickt und macht Gewinn.