.NET / Managed DirectX: Wie reagiert die Spieleindustrie darauf?
-
Ich bin grad dabei, mich langsam in .NET einzulesen, was ja ziemlich im Kommen ist. Mit Managed DirectX ist jetzt ja auch eine DirectX-Version für .NET verfügbar.
Jetzt wollt ich mal fragen, wie die Spieleproduzenten darauf reagieren. Stellen die langsam ihre Engines auf .NET um oder bleiben die noch ne Weile auf Win32-Anwendungen?
Und wie wirds vielleicht in ein paar Jahren aussehen, wenn sich Longhorn bzw das .NET-Framework verbreitet hat?
-
Hi,
also ich denke, die kommerziellen Spieleschmieden werden genau dann umsteigen, wenn für sie außer Frage ist, dass unter diesem Framework eine größere Performance zu erreichen ist, als unter 'konventionellen' Methoden.
Die Verfügbarkeit auf den Rechnern der Kunden ist natürlich auch ein Kriterium.Hobbyentwickler, die gleich mit C# anfangen, werden vermutlich auch gleich dazu greifen.
Dann gibt es noch die Sparte, für die es wohl überhaupt nicht in Frage kommt(Das sind dann wohl die, die eh OpenGL nehmen und mit einer Portierung zu Linux liebäugeln.)Ich steig jedenfalls in absehbarer Zeit nicht um - sehe dazu auch keinen Grund.
Es ist ja nicht so, dass andere Systeme (MacOS) keine interessante Alternative böten. Also einfach mal abwarten...
-
SeppSchrot schrieb:
Hi,
also ich denke, die kommerziellen Spieleschmieden werden genau dann umsteigen, wenn für sie außer Frage ist, dass unter diesem Framework eine größere Performance zu erreichen ist, als unter 'konventionellen' Methoden.
wohl eher, sobald absehbar ist, dass die Performance annaehrend gleich ist bzw. der Performanceunterschied nicht ins Gewicht faellt. Ich glaub nicht dass C# als JIT-Technologie schneller ist als C++. Zumindest nicht in allerabsehbarster Zeit.
Wenn du mit "Performance" allerdings die "Programmier"-Performance meinst, stimm ich zu. C# ist mehr "high level" als C/C++, und deshalb wohl leichter/schneller progrmmiert.Die Verfügbarkeit auf den Rechnern der Kunden ist natürlich auch ein Kriterium.
die spielte bei DirectX auch nie eine Rolle, deshalb glaub ich nicht, dass die Verbreitung des .NET-Frameworks das Problem ist. Das kann man ja immer noch auf der Installations-CD mitliefern.
Dann gibt es noch die Sparte, für die es wohl überhaupt nicht in Frage kommt(Das sind dann wohl die, die eh OpenGL nehmen und mit einer Portierung zu Linux liebäugeln.)
Ich glaub nicht, dass eine OpenGL-Implementierung fuer C# lang auf sich warten laesst (wenn es nicht schon eine gibt). Und Mono macht recht schnell Fortschritte, da seh ich eigentlich kein Problem in der Portierung nach Linux.
Ich glaub, man sollte auch nicht ausser acht lassen, dass Spieleprogrammierer "faul" sind. Wozu auf C# umsteigen, wenn das ganze Entwicklerstudio fit in C++ ist... Da wird der Umstieg eher langsam erfolgen, wenn neue Leute nachkommen, deren Sprache der Wahl nicht mehr C++, sondern C# ist.
just my 2 cents
-
ok, wenn ich dich (Blue-Tiger) richtig interpretiert habe, wäre es an der Zeit, sich mit C# weiter auseinanderzusetzen, für den Fall, dass man mal in solches Buissnes einsteigen möcht. (in sagma mal 5 Jahren ca.)
Blue-Tiger schrieb:
Ich glaub nicht dass C# als JIT-Technologie schneller ist als C++. Zumindest nicht in allerabsehbarster Zeit.
Wird dies jemals sein? (außer wenn Win32 nur noch emuliert wird und dessen Executables deshalb langsamer sind)
-
Chimaira schrieb:
ok, wenn ich dich (Blue-Tiger) richtig interpretiert habe, wäre es an der Zeit, sich mit C# weiter auseinanderzusetzen, für den Fall, dass man mal in solches Buissnes einsteigen möcht. (in sagma mal 5 Jahren ca.)
Blue-Tiger schrieb:
Ich glaub nicht dass C# als JIT-Technologie schneller ist als C++. Zumindest nicht in allerabsehbarster Zeit.
Wird dies jemals sein? (außer wenn Win32 nur noch emuliert wird und dessen Executables deshalb langsamer sind)
Naja, meine Erfahrungen mit Spieleprogrammierung ist eher theoretischer Natur, aber ich denk schon, dass du damit gut zu fahren kommst. Mit "Arena Wars" ist bereits ein Spiel publiziert worden, das in C# geschrieben wurde, und anscheinend sind die Leute gut gefahren damit.
Ob C# jemals schneller als C++ sein wird weiss ich nicht. Man hoert immer wieder, dass JIT-Compiler auch Vorteile haben, da sie z. B. auch JIT-Optimierungen durchfuehren koennen, etc. Momentan wag ich zu behaupten, dass C++ C# in der Hinsicht ueberlegen ist. wie's spaeter mal aussieht weiss ich nicht.
Ob du in 5 Jahren mit C++ oder C# bessere Chancen hast, ins Business einzusteigen weiss ich nicht. Ich glaub aber wesentlich wichtiger als die Sprache, die du sprichst ist aber, was du (mit der jeweiligen Sprache) so alles drauf hast
-
Blue-Tiger schrieb:
Ich glaub nicht dass C# als JIT-Technologie schneller ist als C++. Zumindest nicht in allerabsehbarster Zeit.
Wird dies jemals sein? (außer wenn Win32 nur noch emuliert wird und dessen Executables deshalb langsamer sind)
Kann ich mir nicht vorstellen. Schließlich wird C# nicht direkt in Maschinencode kompiliert sondern in einen Bytecode der interpretiert werden muss. Wird wohl immer um einen konstanten Faktor langsamer sein. (Behaupte ich nach bestem Wissen, wenns falsch ist bitte schreien)
-
Blue-Tiger schrieb:
Mit "Arena Wars" ist bereits ein Spiel publiziert worden, das in C# geschrieben wurde, und anscheinend sind die Leute gut gefahren damit.
Cool, gut zu wissen
(Man lernt nie aus
)Blue-Tiger schrieb:
Ob du in 5 Jahren mit C++ oder C# bessere Chancen hast, ins Business einzusteigen weiss ich nicht. Ich glaub aber wesentlich wichtiger als die Sprache, die du sprichst ist aber, was du (mit der jeweiligen Sprache) so alles drauf hast
Klingt einleuchtend *g*
0x00000001 schrieb:
Schließlich wird C# nicht direkt in Maschinencode kompiliert sondern in einen Bytecode der interpretiert werden muss. Wird wohl immer um einen konstanten Faktor langsamer sein.
Soweit ich das verstanden hab wird beim ersten ausführen ne Exe erstellt, deswegen dauert das meist länger, dafür wird die aber für den entsprechenden PC optimiert oder ähnlich. (Is bei Überlegungen nachm Überfliegen einer .NET-Beschreibung rausgekommen, kann also auch kompletter bulls**t sein
)
-
Entscheidend ist nicht alleine die Geschwindigkeit, sondern ob die erwiesen höhere Entwicklungseffizienz die (immer geringer werdenden) Geschwindigkeitseinbußen ausgleichen.
Ganz entscheidend ist dabei euch die Art der Anwendung - ein Spiel, dass nicht absolute High-End Grafik bieten muss (Doom3, HL2, Stalker) kann bereits heute in MDX entwickelt werden.
Da die Spielebranche eher konservativ ist, die meisten Entwickler noch mit C++ vertraut sind und Großteile des geschriebenen Codes C++ ist, werden die meisten so schnell wohl nicht auf MDX umsteigen.
Ich habe jedoch überhaupt keinen Zweifel, dass Managed DirectX und ähnliche Programmierkonzepte mittelfristig C++/native DX verdrängen werden.@0x00000001: Managed Code ist NICHT wegen des Zwischenschritts über ByteCode langsamer (der ja als Maschinencode ausgeführt wird), sondern wegen der Architektur des .NET Frameworks (Stichwort Schichten/Sicherheit)
-
arena wars nutzt aber wohhl auch nicht directX, oder? ich würde es als freakware dahinstellen
ich seh zum einen keinen grund auf c# umzusteigen, zum anderen seh ich große nachteile darin, dass man über manche dinge die extrem wichtig sind keine kontrolle hat. es ist ja schön als stöpselware für normale windowsapps, 1000mal besser als c++ mit mfc (was die alternative seitens MS ist). aber für spiele sollte man schon genau wissen was passiert und es auch kontrollieren. ansonsten wären die spieleprogrammierer schon vor jahren auf java umgesprungen.
das es viele nachteile bringt sieht man an dem fallbeispiel j2me. es ist hip, es ist neu, es hat nen garbage collector und managed für dich viele dinge, aber genau das muss jeder entwickler aushebeln, damit es auch wirklich immer richtig läuft.
oder um John carmack mal zu zittieren (aus http://www.armadilloaerospace.com/jc):
Write-once-run-anywhere. Ha. Hahahahaha. We are only testing on four platforms right now, and not a single pair has the exact same quirks. All the commercial games are tweaked and compiled individually for each (often 100+) platform. Portability is not a justification for the awful performance.
und so ging es mir dabei auch als ich j2me testete. mophun und brew hingegen liefen auf anhieb bei mir wie erwartet, mein einmal allokierter speicher zum anfang des spiels wurde niemals mehr reallokiert oder ergänzt und nur zum ende gefreet.
wenn man sich ne gute 3d engine anschaut für pc oder konsolen entwicklung, dann wird man auch sehen, dass so gut wie nicht mit dem speicher rumgeranzt wird, man hat einmal eine große allokation und kann dann in einer stackartigen allokations und deallokationsganz reihenfolge arbeiten, oder man freet einfach alles einmal zum ende z.b. eines levels bzw sieht es als gefreet an.
dazu muss man natürlich ein gutes design haben, man kann sich nicht leisten eine list zu benutzen, die für jedes element das man einfügt mal new aufruft
usw.deswegen seh ich wichtige vorteile von c++ verloren in c#, wenn man irgendwann vielleicht garnicht mehr drauf achten muss wie es richtig zu machen ist, sondern jeder hobby sql programmierer sein 3d zogg machen kann, wird es chancen für c# geben. aber wenn man wirkliche AAA titel machen möchte, wird man sein hirn nicht gegen eine laufzeitumgebung tauschen können.
rapso->greets();