Zitat Zitat von Whiz-zarD Beitrag anzeigen
Ich weiß zwar nicht, mit was ihr euer Spiel entwickelt, aber ich würde euch raten, mal XNA anzuschauen, falls ihr das nicht schon tut. Das Framework ist sehr mächtig und auch recht gut dokumentiert.
Jab, wir benutzen XNA. Aber ehrlich gesagt bin ich davon nicht nur begeistert. XNA bietet zwar ein nettes Framework, mit dem man schnell in eine Engine einsteigen kann und die wichtigsten Funktionen gleich schon geboten bekommt (was auch durch die Einfachheit von C# noch unterstützt wird), oftmals ist aber gerade dieses hohe Level genau das Problem. Bestimmte Tweaks am zu Grunde liegenden System sind erst gar nicht möglich ohne eine komplett eigene Engine zu schreiben. Die Erfahrung habe ich jedenfalls gemacht, wenn es beispielsweise um so Sachen geht wie Timing. Konkret habe ich mal versucht, Interpolation in ein Spiel einzubauen. Und obwohl auf MSDN steht, dass in XNA die Draw-Methode selbst dann noch möglichst oft aufgerufen wird, wenn man das Spiel auf Fixed Time Steps stellt, hat das bei mir nicht so wirklich funktioniert. Faktisch wurden Update und Draw bei mir immer noch gleich oft aufgerufen. Beispielsweise hatte ich mal testweise die Update-Frequenz auf 4 FPS gesetzt. Der Effekt war, dass auch Draw nur mit 4 FPS aufgerufen wurde. Solches Verhalten zu verändern wird in XNA beispielsweise nicht leicht.

Eine andere Sache, die mir in XNA nicht gefällt, ist dass es viele Sachen komplizierter macht als nötig. Zur Erläuterung: In unserem Spiel gibt es einen Laser, der Ray-Tracing verwendet und genau bis zur nächsten Wand fliegt. Zur Darstellung verwenden wir Tiles, die wir x-mal wiederholen. Nun dachten wir uns, dass es vielleicht einen ganz guten Effekt gäbe, wenn wir den Laser per Add-Blending darstellen. War auch an und für sich keine schlechte Idee, nur haben die Tiles sich an den Übergängen überlappt (was in XNA sonst kaum anders lösbar wäre aufgrund gewisesr Eigenschaften), was bei Add-Blend natürlich bedeutet, dass an dieser Stelle doppelt addiert wird und man Übergangskanten hat. Schön und gut dachte ich mir. Zeichne ich den Laser einfach vorher per Alpha-Blend auf einen Buffer und dann von da per Add-Blend auf den Bildschirm. Aber nein, Pustekuchen. Das einzige, was ich dafür hätte verwenden können, sind RenderTargets. Und die sind einfach so ziemlich das schlimmste, was es in XNA gibt. Jeder, der damit schonmal gearbeitet hat, kennt sicher das Problem mit der lilanen Farbe im Hintergrund. Ich schwöre: Ich habe ein paar Stunden lang gegoogelt und diverse als funktionierend abgestempelte Methoden teilweise eins zu eins übernommen. Ich habe es einfach nicht geschafft, die Farbe rauszukriegen. In anderen Libraries, beispielsweise Allegro, hätte ich an diesem Problem vielleicht fünf Minuten gesessen.

Also wie gesagt: XNA ist schon ein nettes Framework für den Einstieg in eine eigene Engine, weil es einem viel Arbeit schon abnimmt, aber für ein wirklich ernsthaftes Projekt, für das ich etwas mehr Zeit hätte, würde ich es nicht verwenden wollen.

Zitat Zitat von Whiz-zarD Beitrag anzeigen
Und außerdem: Du arbeitet sehr wohl mit Pointern in C#. Nur nennen sich diese hier Referenzen.
Wenn du ein Objekt instanzierst, bekommst du als Rückgabewert ein Pointer auf dein Objekt.
Klar. Habe ich denn was anderes behauptet? Ich bin ja nicht auf den Kopf gefallen. Natürlich sind Referenzen in C# nichts anderes als Pointer. Fakt ist aber, dass du sie nicht als Pointer verwendest. Das macht C# eben schon automatisch für dich. Für dich als Programmierer hingegen gibt es in C# in der Nutzung erstmal keinen Unterschied zwischen Reference-Typen und Value-Typen, die werden alle wie letzterer verwendet. Was ich damit sagen will: Wenn du beispielsweise eine Funktion mit Parametern schreibst, macht es für dich keinen Unterschied, ob du einen int übergibst oder eine Klasse. C# wählt automatisch die bestmögliche Option für dich. In C++ hingegen müsstest du selbst entscheiden, ob du die Klasse lieber als Daten oder als Referenz übergibst.

Auch das alles hat natürlich nicht nur gute Seiten. Ein Problem hiervon ist zum Beispiel, dass du an die Vorgaben von C# gebunden bist. So kannst du beispielsweise einen int niemals als Referenztyp und eine Klasse niemals als Valuetyp übergeben. Das ist zwar nur in den seltensten Fällen überhaupt nötig, aber durchaus nicht komplett ausgeschlossen. Zumindest der erste Fall. Um das in C# hinzukriegen musst du schon einen Umweg gehen und den Valuetyp irgendwie extra in eine Klasse packen. Und das ist eben genau das, was ich meine. Wirklich mit Pointern arbeiten tust du in C# eigentlich nur in Unmanaged Code. Ansonsten tut C# das automatisch und es kann dir egal sein, ob da gerade Pointer verwendet werden oder nicht. Eben auch wegen der automatischen Speicherverwaltung und so.