XNA Game Studio - Eure Einschätzung

[Matze]

Hallo,

ich bin jetzt seit ca. zwei Monaten mit XNA am rumspielen und habe als erstes Testprojekt - man höre und staune - einen Pong-Clone programmiert. Wenn man es ganz genau nimmt, ist das eigentlich mein erstes fertiges Spiel. Zwar habe ich auch früher schon mit Direct3D und C++ diverse Sachen angefangen, aber die Kompexität und der gewaltige Umfang von Direct3D hat mir irgendwann immer die Motivation genommen. Zudem nervt es mich bis heute, dass man immer erst einen ganzen Batzen Code schreiben muss, bevor man überhaupt erstmal ein Fenster bekommt.

XNA macht es einem da in vieler Hinsicht sehr viel leichter. Und genau da stellte sich mir die Frage, was XNA überhaupt ist bzw. sein möchte? Ist es ein Framework, mit dem selbst Nicht-Hardcore-Spieleprogrammierer es schaffen ein Spiel zu programmieren, oder richtet sich XNA vor allem auch an professionelle Entwickler? Oder vielleicht auch anders gefragt: Wo liegen die Grenzen von XNA? Eignet es sich nur für kleinere Spieleprojekte oder ließe sich damit auch (und zwar nicht nur theoretisch) ein X3, Freelancer, Half-Life 2, Oblivion, etc. programmieren. Gibt es eine bekannte Spieleschmiede, die XNA einsetzt? Gibt es Argumente für bzw. gegen XNA? Eure Meinungen und Erfahrungen würden mich sehr interessieren.

Beste Grüße,
Matze

[Chromanoid]

Also ich finde XNA ziemlich gut. Ich habe damit mal für die Uni ein Minispiel in 3D gemacht. Das ganze war mit 3D Modellen innerhalb eines Wochenendes schaffbar (ohne Physik oder so)... Das hat mich ziemlich von dem Ding begeistert. Außerdem finde ich die Vorstellung gut damit auch für die XBox360 zu entwickeln und Spiele evt. mal über XBLA zu publishen.... Aber Links wie http://www.gamedevblog.com/2007/03/some_answers.html schränken diese Vorstellung ein.
Mich persönlich stört vor allem das Ressourcen-Management von XNA. Ich glaube das würde bei großen Spielen am ehesten Probleme machen...

XNA lässt sich wohl am ehesten als gutes Prototyping Framework oder als Grundlage für Casual-Games sehen. Die mit XNA entwickelten Produkte sind so ziemlich alle im Casual-Bereich anzusiedeln und sind wenn sie publiziert werden vor allem über den Xbox Live marketplace abrufbar. Xbox LIVE Community Games können mittlerweile wohl auch recht unproblematisch hochgeladen werden und man kann gleich geld verdienen :). http://blogs.msdn.com/xna/archive/2008/ ... games.aspx

Das XNA Game Studio richtet sich definitiv an Hobbyspieleentwickler und ist damit ja auch vor allem in Amerika sehr erfolgreich.

Die Spieleentwicklung damit ist also ohne Einschränkung zu empfehlen, wenn man schnell kleine bis mittelgroße Spiele in einem kleinen Team für Windows und (mit Performance-Einschränkung und kleineren Macken) für XBox entwickeln möchte. Dabei sollte man sich der Nichtportierbarkeit und der auf Hobbyentwicklung bzw. eher kleine Spiele fokussierten Architektur bewusst sein.

[Richard Schubert]

Es geht schon eine ganze Menge mit XNA. Mein Wipeout Klon ist leider noch nicht zeigungswürdig, aber rendert ein paar hundert tausend polygone auf den Screen, läuft mit richtiger Physik und 60 FPS auf der XBox und das bei nur simplen optimierungen. Welche kleineren Macken soll es denn geben, die das auf der Xbox so problematisch machen sollen?

Klar eckt man schnell an den Grenzen der Xbox an, da die Hardware auch schon mehr als drei Jahre alt ist. Grafisch kann man ohne Probleme das gleiche abfeiern, was auch irgendein AAA Game macht. Wenn es um komplexe Algorithmen auf der CPU geht, muss man sich natürlich was einfallen lassen. Threading oder andere kleine Dinge, die man beachten muss, reichten mir bisher aus um meine Ziele zu erreichen.

Wer ein echtes AAA Game erstellen will, muss natürlich auf XNA verzichten, aber jedes XBLA Game oder XBLCG kann oder sollte damit schon entwickelt werden. Alles andere Ist Resourcenverschwendung. Außer man hat natürlich die Ambition auch auf PSN, Wii, iPhone, Linux oder Mac zu releasen.

Die Content Pipeline empfinde ich auch als eine der größten Stärken und nicht als Schwäche. Sobald das Team ein wenig größer wird, muss sich natürlich nen kleines Content Tool bauen, womit man Content als Artist laden kann. Aber sobald man das hat, ist man viele Probleme los. Sounds, Curves, XML, Fonts, Meshes, Music, Textures, all diese Dinge müsste man einzeln implementieren und warten. Mit XNA muss man gar nichts tun als diese zu laden.

Wer die Wahl hat, dem würde ich uneingeschränkt XNA empfehlen. (AAA Games und andere Märkte ausgenommen)

[Matze]

Erstmal vielen Dank für Eure Antworten.

Wer die Wahl hat, dem würde ich uneingeschränkt XNA empfehlen. (AAA Games und andere Märkte ausgenommen)

Da stellt sich mir natürlich die Frage, warum nicht wesentlich mehr Leute ihre Spiele mit XNA entwickeln. Gerade in so einer Spieleprogrammier-Community wie hier dürften doch die wenigsten den Anspruch haben einen AAA Titel zu programmieren. Nach allem was ich kenne und über XNA gelesen habe, ließen sich damit absolut vorzeigbare Spiele erstellen, die zwar in Sachen Portabilität natürlich Abstriche machen müssen, aber dafür durch entsprechende Unterstützung vom XNA-Framework in wesentlich kürzerer Zeit fertiggestellt werden können, weil man sich nicht erst um das ganze Drumherum kümmern muss, sondern direkt mit der Umsetzung des Gameplays und der Spiellogik beginnen kann. Ich kann mir eigentlich keinen plausiblen Grund denken, warum jemand, der sowieso auf Windows und DirectX entwickelt, nicht zu XNA greifen sollte, sondern stattdessen lieber die "umständlichere" Variante des "Alles-Selber-Codens" wählt. Oder gibt es vielleicht hinsichtlich des Verkaufs von eigenen, mit XNA erstellten Spielen irgendwelche Lizenzbeschränkungen von Microsoft?

[Seraph]

@Matze: Ich denke es kommt erst mit der Zeit, viele sind dabei etwas zu entwickeln und nutzen halt noch DX/OGL, dazu kommt, dass nicht wenige aus welchen Gruenden auch immer versuchen portabel zu sein. Ein weiterer Grund ist, dass viele zuviel Wert auf die Grafik legen und nie bis zum eigentlichen Spiel kommen, wobei selbst dafuer wohl XNA geeignet waere. Aber naja, XNA ist halt Microsoft, was sicher auch einige abschrecken wird. Ach ja, es ist neu und neue Dinge schrecken auch ab.

Wie gesagt, gib XNA Zeit. Es gibt hier allerdings schon ein paar die damit arbeiten, zumindest ein nicht geringer Teil der "Gruenen" und zumindest einer der "Roten". *g* Wir haben uns nach einigen Ueberlegungen auch fuer XNA entschieden, ein grosser Pluspunkt war dabei auch C#. Ich bin gespannt wie weit wir kommen werden, aber wahrscheinlich weiter als mit den alten Mitteln, da man hier nunmal bedeutend weniger selbst machen muss, sich nicht alles aus 20 verschiedenen Libraries zusammen suchen muss, etc.

[Ysas]

Ich beschäftige mich auch seit einiger Zeit mal mehr mal weniger mit XNA.

Die Vorteile für mich:
- C#
- Content Pipeline
- Wenn man XBOX Support vernachlässigt kann man so ziemlich alles machen was man will. Nur etwas schneller programmiert als mit DirectX (=persönliche Meinung)
- Es gibt sehr viel Samples und Libraries wie z.b. PhysX (daher XBOX vernachlässigen :P )
- Wenn man mal ein paar Wochen/Monate Pause macht kommt man schnell wieder rein und kann weiter arbeiten.
- Microsoft; Ja sowas kann auch ein Vorteil sein. XNA wird sicher noch einige Zeit existieren und auch weiterentwickelt.

Nachteil sehe ich eigentlich keinen. Die Zeit die ich beim Programmieren spare kann ich in Optimierungen stecken also ist das Ergebniss gleichwertig oder besser.

Warum es noch keine Spiele wie X3, Half Life,... gibt liegt sicher am "alter" von XNA. Solche Spiele brauchen Jahre an Entwicklung und Profis.
Aber man wird sehen was die Zukunft bringt.

[Chromanoid]

Ich denke für viele ist außerdem der Spaß eben das zu entwickeln was XNA schon implementiert hat. Genauso kann man sich fragen, warum so wenig Leute hier im Forum für Flash usw. entwickeln oder vorgefertigte Engines benutzen. Den meisten gehts eben nicht um das Fertigstellen von Spielen sondern nur um deren Entwicklung im technischen Sinne.

Ich glaube, dass das Ressourcenmanagement bei größeren Spielen zu wenig Kontrollmechanismen erlaubt. Dynamisches Laden und Entladen von Ressourcen in einer großen grenzenlosen Spielwelt mit vielen Texturen usw. kann (nur eine Vermutung) evt. zu einem Problem werden. Ich weiß nicht wie gut man da einfach mehrere ContentManager einsetzen kann. XNA erlaubt es ja soweit ich weiß Ressourcen nur zu entladen, wenn man ContentManager.Unload() ausführt und das sind dann alle vom ContentManager geladenen Ressourcen...

Ebenfalls war es glaube ich recht schwierig eine Modding-Schnittstelle für ein XNA Spiel einzubauen oder überhaupt dynamisch Ressourcen zu laden. Sobald man das tun will musste man soweit ich mich erinnere (ich hab mit XNA 2.0 gearbeitet) am eingebauten Content Management vorbeientwickeln. Aber dies scheint mit XNA3 glaube ich alles viel besser geworden zu sein und gilt nicht mehr.

Aber bei kleinen bis mittelgroßen Spielen sind diese Dinge eh unbedeutend. Und ich muss ehrlich gestehen, dass ich erst seit dem ich heute mal recherchiert habe verstanden hab, warum es so sinnvoll ist, den Content so wie in XNA vorzubereiten. Ich zitiere dazu mal einen Blogeintrag, der mir da auf die Sprünge geholfen hat:

The idea of processing assets during the build will be familiar to anyone who has worked on a console game, but may come as a surprise to people from a Windows background. There are actually several reasons why this is a good idea:

• Windows has a very rich programming environment with many helper programs and libraries that can be useful for loading and converting asset files. Most of these libraries are not available on Xbox, so the only way to get access to them is to pre-process the assets on a Windows machine.
  Game consoles only have limited amounts of RAM, and no virtual memory. Asset processing can need a lot of temporary memory, so it makes sense to run this on Windows during the build process.
• Converting game assets into a format that is ready to render can take a long time. If we did this work while loading the asset, it would slow down load times for everyone who plays the game. By moving processing operations to the build process, the developer only has to process the content once, after which it can be loaded nice and quickly for everyone who plays the game.
• By processing assets during the build, we can throw away any data that is not actually required by the game. This minimizes the size of the final game distributable.
• The more processing work is done during the build, the more errors can be reported up front, rather than only being spotted as a runtime crash when you later try to load that content.

Somit ist meine Kritik am Content-Management von XNA vor allem meinem Unwissen zu verdanken :).[/b]

Mich persönlich hat im Moment Java mit Webstart und Flash ziemlich in den Bann gezogen, was der einzige Grund ist warum ich mich nicht mehr mit XNA beschäftige.

Aber was ich wirklich blöd an XNA finde ist der Name :D, da hätte man sich was schöneres ausdenken können „XNA’s Not Acronymed“ ist echt ein schlechter Witz (finde ich)...

Auf Bald
Chromanoid

[Tactive]

Hallo,
ich habe mich ein wenig mit C# und DIrectX 9 beschäftigt (weil es ja keine C# Unterstützung für DirectX 10 gibt - es sei denn man nimmt SlimDX). So richtig begeistert war ich davon aber nun nicht, vor allem vermisste ich eine ordentliche Dokumentation der C# Schnittstelle. Beim XNA ist das zum Glück anders, dort gibt es eine ordentliche Doku. Von daher denke ich das ich mir das auch mal ansehen sollte. Ich progge zwar gerne unter C++ aber da bricht man sich meistens allein schon bei Kleinigkeiten die Finger.

[Matze]

Zum Thema Content-Pipeline bzw. Content-Management: Ich muss sagen, dass ich es als sehr angenehm empfinde, dass man einfach so Meshes, Sounds, Musik, Bilder, etc. ins Projekt importieren kann und einem diese dann einfach per Content.load(...) zur Verfügung stehen. Aber was macht man eigentlich, wenn man sich bspw. einen Leveleditor, Wordbuilder, oder was auch immer programmiert hat, der einem Leveldaten in einem eigenen Format ausspuckt, die man gerne innerhalb des Spiels dynamisch laden möchte? Da es sich hierbei nicht um ein Standardformat handelt, funktioniert das wohl kaum über die Content-Pipeline. Gibt es denn überhaupt die Möglichkeit die Content-Pipeline für solche Fälle zu umgehen, um eben doch dynamische Inhalte laden zu können? Ich vermute mal, wenn so was geht, dann zu Lasten der XBOX 360 Unterstützung, oder?

Einen wesentlichen Kritikpunkt habe ich übrigens: Ich finde es schade, dass man für teures Geld eine XNA Creators Club Mitgliedschaft braucht um seine Spiele auf der XBOX zu spielen. Würde es sich hierbei um eine Gebühr für die Nutzung des Marketplace handeln, dann wäre das aus meiner Sicht okay, aber ich kann mein eigenes Spiel nicht mal auf meiner eigenen XBOX testen, ohne einen Haufen Geld abzudrücken. Da sollte Microsoft vielleicht in Zukunft nochmal nachbessern.

[Tactive]

Aber was macht man eigentlich, wenn man sich bspw. einen Leveleditor, Wordbuilder, oder was auch immer programmiert hat, der einem Leveldaten in einem eigenen Format ausspuckt, die man gerne innerhalb des Spiels dynamisch laden möchte? Da es sich hierbei nicht um ein Standardformat handelt, funktioniert das wohl kaum über die Content-Pipeline. Gibt es denn überhaupt die Möglichkeit die Content-Pipeline für solche Fälle zu umgehen, um eben doch dynamische Inhalte laden zu können?

So wie ich das mitbekommen habe, ist es Möglich die Content-Pipeline zu erweitern, also quasi sich einen eigene Importer schreiben zu können.
Mehr Infos dazu findest Du auf folgender Seite: http://www.xnamag.de/index.php

Einen wesentlichen Kritikpunkt habe ich übrigens: Ich finde es schade, dass man für teures Geld eine XNA Creators Club Mitgliedschaft braucht um seine Spiele auf der XBOX zu spielen. Würde es sich hierbei um eine Gebühr für die Nutzung des Marketplace handeln, dann wäre das aus meiner Sicht okay, aber ich kann mein eigenes Spiel nicht mal auf meiner eigenen XBOX testen, ohne einen Haufen Geld abzudrücken. Da sollte Microsoft vielleicht in Zukunft nochmal nachbessern.

Was kostet denn diese Mitgliedschaft? Ich finde Konsolen ja generell viel zu teuer, von daher sollte M$ doch froh sein wenn Sie die Dinger los werden.

[Richard Schubert]

Ja so ein Import zur Laufzeit im Editor ist möglich. Den erstellten Content dann auch dynamisch zu laden ist auch möglich (PC und Xbox). Da die Content Pipeline auf MSBuild aufbaut, kann man sie einfach als API einbinden. Ich könnte meinen Content Importer ja mal zur Veranschaulichung hochladen wie das geht. Und gezieltes Endladen der Assets zur Laufzeit ist ebenfalls möglich indem man mehrere ContentManager verwendet. Das empfinde ich zwar auch nicht als eine gute Lösung, aber immerhin es geht.

Die Creators Club Mitgliedschaft kostet 100€ pro Jahr oder 40€ für drei Monate. Wer sich hier noch registriert, bekommt sie sogar kostenlos. Damit erwirbt man sich nicht nur die Test- und Debugmöglichkeiten auf der Xbox, sondern auch die Möglichkeit auf dem Marketplace zu publishen. In Deutschland ist das allerdings noch nicht zugänglich. :(

Die Konsole Selbst kostet nicht mal 200€ und ist damit wesentlich billiger als ein vergleichbarer PC (nicht dass man einen vergleichbaren PC kaufen wollen würde ;) ).

[Seraph]

Ein Tutorial welches angibt einen anderen Weg (als mehrere ContentManager zu benutzen) zu gehen gibt es hier. Ich bin gestern zufaellig darueber gestolpert, eigentlich war ich auf der Suche nach etwas anderem. Da ich bei unserem Projekt nicht viel mit dem ContentManager zu tun habe, ist es fuer mich nur wenig interessant, von daher habe ich es mir auch nicht wirklich angesehen, aber ich dachte es passt ganz gut hier rein.

[Richard Schubert]

wow, kewle Sache das. Sieht sehr vielversprechend aus, vor allem das asynchrone Laden. Sowas hätte natürlich von Anfang in der Content Pipeline vorhanden sein müssen. Aber wie man sieht, sind alle Hürden der vorhanden Content Pipeline überwunden worden, sodass keine Wünsche offen bleiben.

[Tactive]

Einzig negativer Aspekt bei XNA bzw. C# ist, das man das ganze Zeug decompilieren also den Quelltext einsehen kann.

[Seraph]

Obfuscators helfen da ein wenig.

[dowhilefor]

Einzig negativer Aspekt bei XNA bzw. C# ist, das man das ganze Zeug decompilieren also den Quelltext einsehen kann.

Das Hauptziel von XNA ist ja auch eher die XBox und Zune gewesen. Das Netzwerkzeug(Matchmaking) bspw. funktioniert nur auf Xbox(nach dem Release zumindest). Und da dürfte es ziemlich schwer werden an die dateien überhaupt ranzukommen. Ausserdem, man kann alles dekompilieren ;)

[Seraph]

Ausserdem, man kann alles dekompilieren ;)

Sein Punkt war wohl eher, dass man es recht problemlos in lesbaren Quellcode zurueck verwandeln kann. Programme gibt es da einige, wie dieses hier. Das ist halt der Nachteil dieser "Plattformen" wie .net, Java, etc. Aber wie gesagt, Obfuscator helfen dabei, dass man es nicht sofort im Klartext lesen kann.

[Tactive]

Habe ich da richtig verstanden das XNA "nur" DirectX 9 unterstützt bzw. verwendet?? Also kann man keine Unified Shader einsetzen, oder?? Das wäre/ist dann aber wirklich Schade.

Ansonsten habe ich noch ein wenig herumexperiementiert und war ja begeistert wie schnell man das Umschalten zwischen Fenster- und Vollbilddarstellung implementieren kann,
ich weiss ja selber wieviel Aufwand das unter C++ ist.

[Schrompf]

Irgendwie vermischen die Leute hier permanent Programmiersprachen und Framework. Es ist doch sinnlos, sich über die Komplexität eines Problems in C++ zu beschweren, wenn man ganz automatisch voraussetzt, dass man das schon selbst lösen will... während man gleichzeitig unter C# ein Framework benutzt und sich freut, dass es nur ein paar Zeilen sind. Logik? Keine in Sicht.

Nebenbei: SlimDX müsste auch DX10 unterstützen, glaube ich.

[Tactive]

Irgendwie vermischen die Leute hier permanent Programmiersprachen und Framework. Es ist doch sinnlos, sich über die Komplexität eines Problems in C++ zu beschweren, wenn man ganz automatisch voraussetzt, dass man das schon selbst lösen will... während man gleichzeitig unter C# ein Framework benutzt und sich freut, dass es nur ein paar Zeilen sind. Logik? Keine in Sicht.

Hmm, es ist ja generell so das die "moderneren" Sprachen wie C# und Java schon von Haus aus einiges mehr bieten als C/C++. Das ist mir bewusst, nur desto älter ich werde desto pragmatischer gehe ich an das Hobby der Spieleentwicklung heran, denn jünger werde ich ja auch nicht - eher im Gegenteil. Und beschweren wollte ich mich auch nicht, nur kundtun wie angenehm ich das entwickeln unter XNA finde.

Nebenbei: SlimDX müsste auch DX10 unterstützen, glaube ich.

Ja, aber ich denke ich bleibe erstmal bei XNA. So wichtig sind die DX10 Features nun auch nicht, man kann eben halt doch nicht alles haben ;)

[Seraph]

Irgendwie vermischen die Leute hier permanent Programmiersprachen und Framework. Es ist doch sinnlos, sich über die Komplexität eines Problems in C++ zu beschweren, wenn man ganz automatisch voraussetzt, dass man das schon selbst lösen will... während man gleichzeitig unter C# ein Framework benutzt und sich freut, dass es nur ein paar Zeilen sind. Logik? Keine in Sicht.

Dir ist schon klar, dass C#/.net auch neue Sprachfeatures eingefuehrt hat? Und eben jene ermoeglichen es diverse Probleme bedeutend einfacher und dadurch auch schneller zu loesen.

[Schrompf]

Dir ist schon klar, dass C#/.net auch neue Sprachfeatures eingefuehrt hat? Und eben jene ermoeglichen es diverse Probleme bedeutend einfacher und dadurch auch schneller zu loesen.

Ja, ist mir klar. Und was hat das mit meinem ursprünglichen Ausspruch zu tun, dass Du ihn dafür zitierst?

C# ist eine feine Sprache. So manche Sachen davon wünschte ich mir auch in C++. Die Delegates zum Beispiel sind eine tolle Erfindung, und die "where"-Klausel in foreach-Schleifen ist eine ebenso offensichtliche Erfindung, dass man sich schon fragt, warum da bisher niemand drauf gekommen ist... Im Gegenzug wünsche ich mir auch einiges von C++ in C#, allen voran - man glaubt es kaum - Destruktoren und mehr Kontrolle über die Speicherverwaltung. Leider würde das eine Änderung eines der grundlegenden Konzepte der Sprache erfordern und demnach wahrscheinlich nie kommen. Nuja... jede Sprache halt für ihre Zwecke. Ich würde C# jedenfalls jederzeit Java vorziehen. Java ist mir zu geschwätzig.

Hat nur leider alles nichts damit zu tun, wie schön oder unschön sich eine Aufgabe in einem Framework umsetzen lässt. Und da regt es mich halt auf, dass manche Leute, die vor Jahren noch alles selbst programmieren wollten, weil fremde Libs ja suspekt waren, sich jetzt über die einfache Umsetzung von Features in einem Framework freuen und das als Sprach-Vorteil nennen.

Gemecker zum Morgen lässt Kaffee schal werden. Grmpf.

Bye, Thomas

[Tactive]

Ich würde C# jedenfalls jederzeit Java vorziehen. Java ist mir zu geschwätzig.

Was ist denn an Java geschwätzig? Dir dürfte doch klar sein von wo M$ sich das Konzept für C# abgeschaut hat? Besonders im Hinblick auf J#, welches eine Totgeburt an sich damals war.

Die Delegates zum Beispiel sind eine tolle Erfindung, und die "where"-Klausel in foreach-Schleifen ist eine ebenso offensichtliche Erfindung, dass man sich schon fragt, warum da bisher niemand drauf gekommen ist...

Sicherlich die Delegates sind schon eine echte Erleichterung. War ist aber mit der "where" Klausel bei foreach-Schleifen? Haben die jetzt sowas? Ist mir jedenfalls neu.

Im Gegenzug wünsche ich mir auch einiges von C++ in C#, allen voran - man glaubt es kaum - Destruktoren und mehr Kontrolle über die Speicherverwaltung.

Destruktoren kannst Du in C# doch verwenden, sind zwar nur ein Acronym fürs Finalize aber immerhin geht es. Bei der Speicherverwaltung tendiere ich in C++ immer mehr zu SmartPointern, was letztlich unter C# ebenfalls verwendet wird - wenn man auch (leider) keine direkte Kontroller darüber hat.

Hat nur leider alles nichts damit zu tun, wie schön oder unschön sich eine Aufgabe in einem Framework umsetzen lässt. Und da regt es mich halt auf, dass manche Leute, die vor Jahren noch alles selbst programmieren wollten, weil fremde Libs ja suspekt waren, sich jetzt über die einfache Umsetzung von Features in einem Framework freuen und das als Sprach-Vorteil nennen.

Warum regt Dich meine Meinung zu einem Framework auf? Muss ich immer konform mit dem sein was Du Denkst oder machst? ;)
Weiss nicht ob ich fremde Libs suspekt fand, wahrscheinlich fand ich es ehere einfach als besonders reizvoll die Dinge selber nachzuprogrammieren. Als Sprach-Vorteil habe ich die Features des Frameworks auch nicht bezeichnet sondern ich bezog das mehr auf das gesamte Umfeld, also die Spiele-Entwicklung im C# Bereich.

[Schrompf]

Ich würde C# jedenfalls jederzeit Java vorziehen. Java ist mir zu geschwätzig.

Was ist denn an Java geschwätzig? Dir dürfte doch klar sein von wo M$ sich das Konzept für C# abgeschaut hat? Besonders im Hinblick auf J#, welches eine Totgeburt an sich damals war.

Ursprünglich mag C# mal von Java abgeschaut sein... inzwischen ist es aber wohl eher andersrum :-) Microsoft hat da eine Menge vorgelegt, und Java hat dann so nach und nach Dinge davon übernommen. Beispiel Generics. Und das Java anscheinend immernoch keine Operatorüberladungen kennt, hab ich ihm so recht nie verziehen... allgemein erschien es mir, als ob ich bei Java für den selben Effekt viel mehr tippen muss als bei C#. Daher mein Eindruck der "Geschwätzigkeit".

Disclaimer: habe seit einigen Jahren kein Java mehr in der Hand gehabt. Ich weiß nicht, wie das bei denen jetzt aussieht.

Sicherlich die Delegates sind schon eine echte Erleichterung. War ist aber mit der "where" Klausel bei foreach-Schleifen? Haben die jetzt sowas? Ist mir jedenfalls neu.

Ok, da habe ich HörenSagen-Wissen weitergegeben. Das war falsch, sorry. Ich habe gerade nach "where" gegoogelt und herausgefunden, dass das eine Art der Anforderungsspezifikation für Generic-Parameter ist. Sowas wie die Concepts in C++ für Template-Parameter, die aber erst mit C++0x kommen sollen.

Ursprünglich dachte ich, dass "where" eine Art Erweiterung von foreach-Schleifen war. Sowas in der Art:

Code: Alles auswählen

struct Bla
{
  int x;
  string y;
};

foreach( Bla b in collection where b.x == 5)
{
}

Und das fand ich eine so natürliche Erfindung, dass ich mich gefragt hatte, warum das nicht vorher schonmal vorkam. Scheint aber nach meiner Googlung jetzt ein Fehlalarm gewesen zu sein.

Destruktoren kannst Du in C# doch verwenden, sind zwar nur ein Acronym fürs Finalize aber immerhin geht es. Bei der Speicherverwaltung tendiere ich in C++ immer mehr zu SmartPointern, was letztlich unter C# ebenfalls verwendet wird - wenn man auch (leider) keine direkte Kontroller darüber hat.

Ja, Destruktoren gibt es. Nur leider nicht scope-basiert, sondern halt GC-basiert. Das ist konsequent im .Net-Umfeld, aber nicht ganz das, wofür ich in C++ Destruktoren benutze.

Warum regt Dich meine Meinung zu einem Framework auf? Muss ich immer konform mit dem sein was Du Denkst oder machst? ;)
Weiss nicht ob ich fremde Libs suspekt fand, wahrscheinlich fand ich es ehere einfach als besonders reizvoll die Dinge selber nachzuprogrammieren. Als Sprach-Vorteil habe ich die Features des Frameworks auch nicht bezeichnet sondern ich bezog das mehr auf das gesamte Umfeld, also die Spiele-Entwicklung im C# Bereich.

Nun, dann habe ich das wohl missverstanden. "wieviel Aufwand das unter C++ ist" klang für mich wie ein Programmiersprachenvergleich, nicht wie ein Framework-Vergleich :-)

Nebensatz: bei dieser konkreten Funktionalität "umschalten zwischen Fenster und Vollbild" ist es mir schleierhaft, warum sie das nicht schon lange in DX reingezogen haben. Das ist doch so elementar, dass es dafür kaum verschiedene Wege oder Anforderungen geben könnte. Aber wer weiß, wie das bei denen intern aussieht...

Bye, Thomas

[Seraph]

Dir ist schon klar, dass C#/.net auch neue Sprachfeatures eingefuehrt hat? Und eben jene ermoeglichen es diverse Probleme bedeutend einfacher und dadurch auch schneller zu loesen.

Ja, ist mir klar. Und was hat das mit meinem ursprünglichen Ausspruch zu tun, dass Du ihn dafür zitierst?

Vielleicht habe ich versucht, deinem Vorwurf mir (und anderen) gegenueber etwas kontra zu geben? Um etwas konkreter zu werden. Mich stoert die Verallgemeinerung. Ich weiss nicht, wo ich die Programmiersprache mit dem Framework vermischt habe, aber Du kannst mich sicher aufklaeren.

[Matze]

Leute, bitte fangt jetzt hier keine Grundsatzdiskussion darüber an, welche Sprache eurer Meinung nach die Bessere ist und welche Sprache wo was abgekupfert hat. Es geht in diesem Thread um XNA und dadurch bedingt vielleicht auch ein wenig um C#, aber nicht um Java, C++, J# oder was auch immer. Ich darf euch also bitten für eure "Meine-Sprache-ist-besser-als-Deine"-Diskussion einen neuen Thread zu eröffnen.

Ein Tutorial welches angibt einen anderen Weg (als mehrere ContentManager zu benutzen) zu gehen gibt es hier. Ich bin gestern zufaellig darueber gestolpert, eigentlich war ich auf der Suche nach etwas anderem.

Ziemlich cooler Artikel. Vielleicht solltest Du öfter mal nach etwas ganz anderem suchen, wenn Du dann über so etwas hier stolperst. ;-) Auf jeden Fall vielen Dank für den interessanten Link.


Beste Grüße,
Matze

[Chromanoid]

Wie sieht's eigentlich mittlerweile mit Animation (insbesondere Bone-Animation) bei XNA aus?
Als ich das letzte Mal mit XNA gearbeitet hab, musste man das noch selbst machen. Gibt es da mittlerweile was gutes eingebautes?

[Richard Schubert]

Wie sieht's eigentlich mittlerweile mit Animation (insbesondere Bone-Animation) bei XNA aus?
Als ich das letzte Mal mit XNA gearbeitet hab, musste man das noch selbst machen. Gibt es da mittlerweile was gutes eingebautes?

Funktionierte eigentlich schon problemlos in XNA 1.0. Sobald du allerdings mehrere Animationen miteinander verblenden willst, musst du selbst Hand anlegen.

[Matze]

Sobald du allerdings mehrere Animationen miteinander verblenden willst, musst du selbst Hand anlegen.

Was meinst Du damit? Kannst Du dazu mal ein Beispiel geben?

[KampfGremlin]

Hallo,

eine hinreichende Lösung bietet XNA leider noch nicht nativ. Wie zb das von Richard erwähnte Animationblending. Es gibt aber zwei gute Bibliotheken: XNAnimation und Hilva Graphics Engine. Zur ersten muss man sagen das atm mehr Samples da sind, sie aber nicht mehr aktiv entwickelt wird. Bei Hilva ist es genau umgedreht. Dort wird es aber neben guten Support, auch bald mehr Samples geben. Auch zu Animationen. Hilva hat weiterhin den großen Vorteil, das es flexibler ist. Beide ersetzen das XNA-Model und das hat bei XNAnimation zur Folge das man dort zB nicht ohne weiteres eigene Shader verwenden konnte.

edith sagt: @matze: XNAnimation is opensource. Folglich kannst du dir dort anschauen wie er das macht....

mfg