Serv,

hier mal kurze fragen:

- Sind .NET OpenGL anwendungen erheblich langsamer gegenüber normal Win32 ?

- Wie sieht das mit dem Speicher Management aus, gibt .NET z.b. erstellen Speicherfrei sofort frei ?

Also sprich wenn man mit Marshal arbeitet, oder springt dann erst der GC an ?
Das wäre z.b. wichtig, wenn man komplexe Structuren hat, die Dynamisch zur Laufzeit wechseln müssen, bsp. Welt mit Vertices, Triangles, Octree etc.

- Macht es sinn Games darin zu basteln, oder sollte man doch lieber ganz normal bei Delphi bleiben ?
Die frage interessiert mich im besonderem auch auf Netzwerk performance, für Client/Server im bereich RPG.



Danke,
Schonmal

Die Performance ist wenn man von ein paar Spezialfällen absieht kaum schlechter. Der RAM-Verbrauch ist jedoch ein Stück höher.

_________________

Stimmt es das Moderne 3D Engines, heutzutage teilweise oder sogar komplett code in .NET enthalten ?

Ist mir irgendwie aufgefallen, weil man für einige neuere Games das .NET Framework brauch.

Kann man also davon ausgehen, das .NET gut für Echtzeit Anwendungen gedacht ist ?
Wäre ja sehr grosser Vorteil, weil man in .NET sehr einfach Modular Programmieren kann.

Die "großen" Engines wie die CryEngine oder die aktuelle Unreal Engine sind in C++ geschrieben. Ein weiterer Grund (abgesehen von der Performance / Spericherverbraucht) ist, dass man so viele Plattformen wie möglich unterstützen möchte, also auch Konsolen. Natürlich läuft C# auch auf der XBox, aber es gibt nur einen C++ Toolchain für Retailtitel.

Ah das alte Thema

Die Performance von .Net (und Java) an sich ist ja recht hoch - Das Problem ist stets die Schnittstelle zwischen dem interpretierten Code und der Grafikkarte (die ja über die opengl32.dll angesprochen wird). Das ist zumindest bei Java wohl recht lahm - wie es bei .Net aussieht, weiß ich nicht... Ich schätze aber mal, dass auch dort die Native API nicht die schnellste ist. Dem kann man aber entgegen wirken, indem man schlichtweg seine Aufrufe reduziert. Will heißen => Weg vom intermediate mode, hin zu VBOs, die man dann mit nur noch wenigen Aufrufen zeichnet.

Speicherverbrauch:
Ja, .Net und Java fressen merklich mehr Speicher als native Anwendungen. Liegt daran, dass im Hintergrund erstmal die VM mitgeschleppt wird und prinzipiell alles doppelt im Speicher ist (Einmal als Bytecode und wenn es interpretiert wird in der nativen Form). Allein das ist schon Hinderungsgrund genug, da Spiele sich ja bekanntermaßen ebenfalls an viel freiem RAM erfreuen und selbiger so natürlich knapp wird.

Dass moderne Spiele-Engines komplett Code in .Net enthalten, höre ich so um ersten Mal und würde darauf jetzt nicht all zu viel geben. Klar, es gibt Spiele, die komplett in .Net geschrieben sind (Und analog in Java), aber das sind nur sehr wenige und auch recht kleine. Beispiel ist das mittlerweile schon nicht mehr ganz so frische Arena Wars. Aber meist wird tatsächlich C++ verwendet. Ganz ohne .Net.

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Ist mir aufgefallen, weil viele neue Games das .NET Framework 2.0 bzw 3.x erfordern.

Also imho spricht insofern nichts gegen die Verwendung von z.B C# wenn du zeit- und evtl. speicherkritischen Code in C, C++, Delphi etc schreibst. Den müsstest du in DLLs ablegen und von .NET aus abrufen, was problemlos möglich ist. Aus eigener Erfahrung weiß ich, das die Java-Schnittstelle zu OGL vergleichweise sehr lahm ist. Wie das bei .NET aussieht weiß ich nicht weil ichs noch nicht getestet hab. In punkto Netzwerk sehe ich kein Grund auf .NET zu verzichten, da der Flaschenhals da wohl nicht die Software sondern in aller Regel die Bandbreite des Anschlusses ist..

Ich kann mir schon vorstellen, dass .NET in Spielen zum Einsatz kommt.. schließlich hat man imho einfach alles was man braucht in diesem Framework.

_________________
I'm not the signature, I'm just cleaning the floor...

Derzeitiges Projekt:
FireBlade Particle Engine (Release R2 2009.06.29)

Dem kann ich zustimmen....allerdings ist das Problem Programmiersprachenunabhaengig.



Paperlapap, hier ist nix doppelt im Speicher, vllt bei Java aber bei .NET ist nur die JIT-Kompilierte Version im Speicher und es sind noch Metadaten vorhanden die aber nur einmal pro Type vorhanden sind.
Grundsaetzlich wird nur deshalb mehr Speicher verbraucht weil .NET Speicher im vorraus Reserviert um eine schnellere Speicherzuordnung zu ermoeglichen( Kein WinAPI calls.... ).

Fuer reine Daten verbraucht .NET nicht merklich mehr Speicher als jede andere Sprache, das wenige was es mehr Verbraucht brauch man eigentlich nicht zu beachten.



Es mag sein das es keine wirklich kompletten Spiele in C# gibt, das mag aber eher daran liegen das die Entwickler Angst haben das die C# Anwendung Performancetechnisch zusammenbrechen koennte( Was ansich totaler Bloedsinn ist ).
Es Zeichnet sich aber ein Trend ab der in Richtung C# zeigt.
Der Grund warum man inzwischen sehr oft .NET braucht fuer Spiele ist, das .NET als der Part der Anwendung benutzt wird der Ausgetauscht wird( Modding ), zudem laesst es sich als Scirptsystem verwenden.



Gruesse aus NY!

_________________
Shareholder und Leitender Entwickler bei Pipedream-Games.

Zitat: Siehst du diesen Park da unten? Jeden Tag lernen sich darin Menschen kennen und verlassen einander. Und du hast dein ganzes Leben Zeit darin zu gehen.