C# ist der Hammer
-
Original erstellt von MaSTaH:
Und zum Thema "UI-Gestaltung genau so einfach wie in Delphi, kein Scheiß WinAPI mehr" (frei zitiert): Hast du schonmal im Visual-Studio die MFC-Wizards und den Resource-Editor entdeckt??? Ist auf jeden Fall auch so einfach wie in Delphi (Delphi sux
)...Ähm... ich denke mal das verdient nur ein eindeutiges *lol*.
Ich will gar nicht von einem Dialog anfangen, der Buttons mit Text und Bild hat (mach mal mit MFC und RC-Edit). Mach doch mal mit MFC und dem RC-Edit einen Dialog, wo das Editfeld am rechten zoombaren Fensterrand hängt und die Buttons für OK und Cancel sich beim zoom mitbewegen. Bereits so eine triviale Aufgabe wird bei MFC aufwendig. Und dann z.B. farbliche Hintergründe für Editfelder, etc. Da rutscht man sofort wieder in WinAPI ab.
Die VCL (egal ob bei Delphi oder beim C++ Builder) mit der MFC zu vergleichen ist ein schlechter Witz. Und der Hammer ist schon, daß die .NET-GUI-Sachen noch mal eines drauflegen im Vergleich zur VCL.
-
also alles in Richtung VB?
-
@fish
Wieso alles Richtung VB?
VCL ist eine recht gute und übersichtliche Klassensammlung, die die WinAPI Wrappt. Finde dagegen ist nichts einzuwenden.Und .net ist auch kein VB, eher eine vereinfachte überarbeitete und erweiterte WinAPI oder so ähnlich. ? wenn man das so sagen kann
?
Nur das mit dem Runtime Compiling find ich echt müllig. Hardcompiled ist immer noch am besten.
-
Das ist wohl der Punkt. Hätte MS die .NET-Lib als Ersatz für die MFC angeboten auf einem VC++7, der ISO-kompatibel ist, dann wüßte wohl jeder wie die Zukunft aussieht.
Aber das mit der VM schreckt schon ab...
-
Original erstellt von Marc++us:
Aber das mit der VM schreckt schon ab...Da muss ich dir recht geben. Hab gestern mal in der Firma etwas mit unserer C# Lizenz gespielt und mir mal es einfaches zusammengeschustert. Ich muss sagen,ich mag das Framework (kein Wunder hat ja auch der VCL-Chefentwickler mitgewirkt und Einfluss genommen (-; ) und ich mag auch die IDE... (ähnelt sehr dem Konezpt von Borland mit Objektinspektor und so). Die Sprache selbst wage ich noch nicht zu beurteilen, sieht aber auch ganz nett aus. Egal ob da nun Elemente und Ideen von Java oder sonst was eingewebt sind.
Was mich allerdings grässlichst stört ist eben die VM. Bei uns fällt die Sprache vorläufig unten raus, denn die Applikationen die wir entwickeln müssen auch noch einem Windows 95 und NT4 gerecht werden und da kommt das .Net Framework leider nicht mehr hin. Auchdie Tatsache, dass ich rund 40MB .Net Framework mit der Applikation vertreiben müsste ist nicht grad das Gelbe vom Ei.
Übrigens, Marc++us: Wenn ich so - nach einem kurzen überblick - das Framework so anschaue, so steht ihm die VCL 6.0 in nichts nach. Auch die unterstützt Anker (was andere Frameworks wie Ilog schon lange unterstützen).
-junix
-
Gegen eine VM ist nichts einzuwenden
wenn es mir Vorteile bringt, wie eben
Plattformunabhängigkeit.Ansonsten ist die VM unnötig wie ein Kropf.
-
So ist es - und die M$ Runtime ist eben nicht Crossplattform.
Außerdem ist ein Runtime Compiler für echt Performance Kritische Sachen echt in die Tonne zu hauen.Wenn ich eine garantierte Reaktionszeit von sagen wir 5 MSek oder noch besser in uSek brauche brauche, ist eine VM noch nicht tragbar. Das wird sich zwar mit den nächsten Rechnergenerationen wieder verbessern, aber dafür baut M$ noch viel mehr Overhead ein, und die Kiste verliehrt mit den ganzen Services, und sonstigem Krempel wieder etwas.
-
Wenn ich eine garantierte Reaktionszeit von sagen wir 5 MSek oder noch besser in uSek brauche brauche
Wenn man sowas wirklich brauchen sollte, dann macht man das sowieso nicht unter Windows oder Linux.
-
Naja, bei Kommunikation ist eine tiefe Reaktionszeit shcon wichtig. grad wenn man ein protokoll fährt, das mit Timeouts arbeitet...
-junix
-
Naja - du hast nur bedingt recht. Gut wenn ich z.B. eine Sensorik Steuerung im nano Sekunden Bereich brauche, dann muß ein Realtime OS her - siehe QNX oder ähnliches.
Wenn man aber Games entwickelt, dann kommt es auch sehr auf die Performance an. Da ist ein Runtime Compiler nicht so toll. Es kommt ja auf jeden Frame an. Und die Zeit, die man dann mehr braucht, um die Daten zu rendern, fehlt einem dann z.B. bei der KI, Physik usw.
-
Jede Sprache hat ihre eigenen Anwendungsgebiete. Und C# ist sicherlich nicht für Games geeignet.
-
Hast du wohl recht dx
C/C++ und ASM sind wohl dafür noch am besten geeignet
-
Original erstellt von <dx>:
Jede Sprache hat ihre eigenen Anwendungsgebiete. Und C# ist sicherlich nicht für Games geeignet.Wofür eigentlich?
-
Für Windows Anwendungen!
-
Original erstellt von <dumm>:
Für Windows Anwendungen!Wie leicht man C#ler doch auf die Palme bringen kann
-
Original erstellt von SnorreDev:
**
Wenn ich eine garantierte Reaktionszeit von sagen wir 5 MSek oder noch besser in uSek brauche brauche, ist eine VM noch nicht tragbar.**Nun, bei Java gibt für die entsprechenden Systeme schon seit mehr als einem Jahr eine "Real-Time Specification". Siehe JSR: http://www.jcp.org/en/jsr/detail?id=1
Es scheint also generell nichts gegen eine VM in diesem Bereich zu sprechen.
Es kommt ja auf jeden Frame an. Und die Zeit, die man dann mehr braucht, um die Daten zu rendern, fehlt einem dann z.B. bei der KI, Physik usw.
Selbst die entsprechenden Java-Bibliotheken (wie z.B. LWJGL oder GL4Java) lassen die vorhandene Grafikkarte für sich arbeiten. Gibt es einen Grund dafür, warum eine Grafikkarte unter Java langsamer arbeitet? Nein! Gerade in diesem Bereich bringt Java einen sehr geringen Performanceunterschied gegenüber Sprachen, wie C++ mit. Auch hier scheint also eine VM nicht hinderlich zu sein.
[ Dieser Beitrag wurde am 06.04.2003 um 19:01 Uhr von Gregor editiert. ]
-
Original erstellt von Gregor:
**Selbst die entsprechenden Java-Bibliotheken (wie z.B. LWJGL oder GL4Java) lassen die vorhandene Grafikkarte für sich arbeiten. Gibt es einen Grund dafür, warum eine Grafikkarte unter Java langsamer arbeitet? Nein! Gerade in diesem Bereich bringt Java einen sehr geringen Performanceunterschied gegenüber Sprachen, wie C++ mit. Auch hier scheint also eine VM nicht hinderlich zu sein.[ Dieser Beitrag wurde am 06.04.2003 um 19:01 Uhr von [qb]Gregor** editiert. ][/QB]
Ich habe die Java GL selbst schon probiert, allerdings ist der Zeitverlust, der zwischen den API calls existiert doch ziemlich horrend. Für kleinere Sachen reicht es auch - aber was für nen Rechner bräuchten Professionelle Games wie M$ Rallysport Challenge, Unreal 2, Doom 3, wenn sie in Java geschrieben währen?
Bei 10 Ghz sind wir noch nicht - und dann ist der Maßstab an Optik wieder höher
-
OK, Sorry! Ich hatte da etwas falsch in Erinnerung. Ich habe gerade nochmal in dem Report nachgeguckt, von dem ich meinte, das gehabt zu haben, aber anscheinend stellt auch der Report in diesem Bereich einen Geschwindigkeitsunterschied von etwa 20-25% fest. Ich dachte, dass das knapper wäre.
10 GHz haben wir wohl in etwa 3 Jahren erreicht, denke ich. Und auch, wenn die Ansprüche steigen, so rückt doch die Leistung der Hardware mit der Zeit etwas in den Hintergrund. Welches Spiel gibt es denn momentan, das auf die beste Hardware angewiesen ist? Ziemlich wenige, wenn nicht garkeine, oder? Vor ein paar Jahren war das anders. IMHO wird mit der Zeit der Mensch der limitierende Faktor. Somit arbeitet auch die Zeit für virtuelle Maschinen bzw. für Sprachen wie Java oder C#. Es spricht ja nichts dagegen, den entsprechenden Code in Maschinencode zu kompilieren. Bei Java gibt es entsprechende Compiler, bei C# weiß ich das nicht, falls sich C# irgendwann mal etablieren sollte, wird es für C# aber auch irgendwann entsprechende Native-Compiler geben.
Es gibt zumindest Spiele, die auch Java nutzen. Das bezieht sich auch auf gute Spiele. Zum Beispiel soll IL-2 Sturmovik (hat in den entsprechenden Tests so um die 90/100 Punkten gekriegt) ganz massiv Java nutzen, allerdings nicht für die 3D-Grafik.
Nicht so gut, aber dafür angeblich 100% Java ist zum Beispiel "Law and Order". Das dürfte etwa ein 65/100-Punkte Spiel sein.
Star Wars Galaxies nutzt Java fürs "Scripting".
[ Dieser Beitrag wurde am 07.04.2003 um 01:28 Uhr von Gregor editiert. ]
-
Als Scriptsprache kann ich mir auch Java sehr gut vorstellen in einem Game.
C# implementationen als Script Sprache kenn ich auch mehrere.Ich meinte ja auch - für den Main code, bei dem es um speed geht, ist es nix.
Aber die Runtime Compiler werden auch schon schneller. Wenn ich an vor 4 Jahren denke ...
-
Original erstellt von SnorreDev:
**
Ich meinte ja auch - für den Main code, bei dem es um speed geht, ist es nix.
Aber die Runtime Compiler werden auch schon schneller. Wenn ich an vor 4 Jahren denke ...**Ja, das stimmt wohl. Ich habe gerade mal ein Bild mit Java im Interpreter-Mode vergrößert. Resultat: Im Vergleich zum rein interpretierten Bytecode, ist die heutige JVM, bei solchen Aufgaben, um einen Faktor 9-10 schneller.
...aber viel schneller wird sie wohl nicht mehr. An die Geschwindigkeit von C++ wird eine JVM wohl bei den meisten Dingen nicht ganz rankommen. 
Ich schiebe den Geschwindigkeitsunterschied einfach mal auf die Sicherheitskonzepte von Java. Ich denke, dass die ne Menge Zeit benötigen, die man sich bei C++ sparen kann. Trotzdem denke ich, dass Java (ud vielleicht auch andere Sprachen mit ner VM) in Zukunft auch für Spiele interessanter wird. Ich bin mal gespannt, was das "Java Game Profile" mit sich bringt, falls es irgendwann mal rauskommen sollte. Wäre doch für Spieleentwickler super, wenn ihr Spiel nicht nur auf dem Windows-PC läuft, sondern ohne eine teure Portierung auch gleich noch auf ner Playstation oder nem Linux-PC.