JLI Spieleprogrammierung

[User_User]

Nachdem ich MFC verwendet habe, bin ich zu .NET gewechselt. Nun will ich DirectX und Menüs verwenden. In meinem Buch zu .NET steht nichts über DirectX, und die Bücher, die ich über DirectX habe, behandeln nichts über Menüs.

Selbst das Tutorial vom DirectX SDK verwendet nicht ".NET", sondern noch alte API-Funktionsaufrufe. Da müssen doch ernste Gründe vorliegen, die für die "altbackene" Programmierung sprechen - oder?

Was ist das Einfachste in diesem Fall?

[Patrick]

Gründe sind einfach:

1. Old School rocks!
2. Extrem viel mehr möglichkeiten
3. leichter zu optimieren
uvm!
_________________
'Wer der Beste sein will muss nach Perfektion streben und jede Gelegenheit nutzen sich zu verbessern.' - KIA
[ German Game Dev | Boardsuche hilft sehr oft | Google rockt | Wie man Fragen richtig stellt | ICQ#: 143040199 ]

[Jonathan_Klein]

Es ist ein wenig schweirig, API Funktionen unter DX zu bnutzen, insbesondere wenn das spiel im Vollbildmodus läuft. Du solltest dir daher schön was eigenes Programmiere, was unter anderem den Vorteil hat, das man es viel besser an den Stil des Spiels anpassen kann. Machen ja eigentlich alle modernen spiele genauso.
Im Prinzip ist das ja auch gar nciht schwer, wenn man shcon mal ne Buttonklasse hat, hat man das wichtigste dann vielleich tnoch Eingabefelder und man kann shcon loslegen.
_________________
https://jonathank.de/games/

[User_User]

Ich will noch folgendes ergänzen. Für Menüs unter MFC bin ich fündig geworden.

In der Dokumentation von Microsofts DirectX 9.0 SDK unter

DirectX C++ | Introducing DirectX 9.0 | Using the DirectX SDK | Programming DirectX with C/C++ | AppWizard

Leider nur für MFC und nichts für .NET.

[User_User]

Nun habe ich das Problem gelöst. Im Prinzip kann man, wenn man Menüs unter .NET programmieren will, prinzipiell die C# oder Visual Basic .NET Programmbeispiele mit einem Texteditor öffnen. Da die .NET-Familie die gleichen Klassen und Funktionen nutzen, erscheint es möglich, sein Programm anzupassen.

Mittlerweile habe ich jedoch herausgefunden, dass sich .NET vor allem für Datenbankprogramme oder verteilte Anwendungen eignet. Dabei habe ich festgestellt, dass Programmierer von Visual C++ in der Regel nicht zu .NET gewechselt sind (wenn schon, dann zu C#). ".NET" ist wesentlich langsamer in Bezug auf schnelle Grafikausgabe. Außerdem hat man nur wenige alte/neue GDI-Funktionen zur Verfügung (zu was anderem fand ich keine Dokumentation). Das Angebot zur 3D-Programmierung unter .NET ist praktisch Null und die stolzen Besitzer der neuen Programmierumgebung sind gezwungen (für schnelle Grafik), so wie bisher zu Programmieren. Deshalb findet man auch praktisch keine Spiele, die Windows-Menüs benutzen.

[malignate]

Die Gründe für das Nichtvorhandensein von .NET Menüs in der Spieleprogrammierung haben wohl andere Gründe.
Man kann Menüs und andere Controls NICHT in Vollbildanwendungen verwenden.
Das heißt es spielt nur in Editoren eine Rolle. Ob man dort dann .NET oder Qt und Konsorten verwendet spielt keine Rolle, die meisten werden aber ihre Lieblings-API schon haben.

Das .NET so viel Langsamer sein soll als unmanaged wage ich mal zu bezweifeln. Gerade heute, wo viele Operationen ausgelagert werden spielt die Rechengeschwindigkeit auf der CPU nicht mehr die allergrößte Rolle. Und auch MDX ist DX. Außerdem erreicht man mit C++ CLI fast die gleiche Geschwindigkeit wie mit C++, zum Teil dank GarbageCollector sogar eine bessere Performance. Zumindest die MDX-Samples aus dem SDK scheinen nicht langsamer zu sein.

[User_User]

Das interessiert mich!

Ich habe das Buch Visual C++ .NET Schritt für Schritt von Julian Templeman, Andy Olsen.

Ich habe es bis einschließlich Kapitel 19 durchgelesen (bis zu xml), aber außer GDI+ fand ich nichts. Im Stichwortverzeichnis ist "DirectX" nicht vorhanden.

Ich habe auch schon den Projekttyp "Windows Forms-Anwendung (.NET)" erzeugt. Als ich den Programmcode von C++ .NET z.B.

Application::Run(new Form1());

mit dem Programmcode von C# verglich:

Application.DoEvents();

erkannte ich, dass ich an vielen Stellen Änderungen vornehmen müsste.

Darüber hinaus fand ich im DirectX SDK Sample Browser nur Beispiele zur Verwendung von DirectX unter MFC ("mfcfog" und "mfctex"). Deshalb ging ich davon aus, dass die Verwendung von DirectX unter C++ .NET auf "technische" Schwierigkeiten stößt.

Könnten Sie mir eine Quelle Buch, oder ähnliches, nennen?

[PeaceKiller]

Im DX-Sample-Browser gibt's doch auch C# Beispiele, oder?
_________________
»If the automobile had followed the same development cycle as the computer, a Rolls-Royce would today cost $100, get a million miles per gallon, and explode once a year, killing everyone inside.«
– Robert X. Cringely, InfoWorld magazine

[User_User]

Ja, es gibt sie. Wenn man die DirectX-Tutorial-Project-Files anklickt (Im DirectX Sample Browser show "C#" und "Tutorial" erhalten ein Häkchen), erfährt man wo. Man kann die Dateien mit der Endung .cs mit einem Editor z.B. WordPad öffnen, muss aber bei dem Fenster "Öffnen" als Dateityp "Alle Dokumente (*.*)" wählen, damit sie angezeigt werden.

Nun ist es aber nicht schön, wenn ich C++ - die Sprache der 3D-Programmierung - beherrsche, C#- oder Visual Basic .NET-Programme ansehen muss, um 3D unter C++ .NET zu programmieren. Ich kam aus der Visual Basic-Ecke (vor der NET-Zeit) und bin wegen der 3D-Programmierung damals zu VC C++ 6.0 gewechselt.

Das Problem ist, dass die automatisch erzeugten Visual C++ .NET-Projekttypen an vielen Stellen unterschiede im Vergleich zu den C#-DirectX-Tutorial Programmbeispielen aufweisen. Und auf die Designer für Menüs oder Formular verzichte ich nicht (das wäre gegenüber MfC ein Rückschritt)!

Ob nun diese Unterschiede das Gleiche bedeuten und wo ich Anpassungen vornehmen müsste, müsste ich im einzelnen nachprüfen. Da bin ich vielleicht schneller wenn ich wieder Visual Basic .NET oder C# lerne.

MFC habe ich begraben. Und ob sich die Mühe lohnt ein vom Anwendungsassisten erzeugten Projektty von Hand anzupassen?

[User_User]

Ich habe nochmals nachgelesen, inwiefern .NET-Programme im Vergleich zu VC 6.0-Programmen langsamer sind.

Auf folgender Seite:

http://www.c-plusplus.de

unter: "FAQs des Forums"

dann: "FAQ - C# und .NET"

dann: ".Net: Grundlegendes"

finde ich folgende Aussagen:

... "DIE Sprache für .NET ist C#, auch wenn .NET "Sprachunabhängig" sein soll." ... Das Anwendungsgebiet von C++ ist zudem größer als das von C# oder Java, da man "systemnah" programmieren kann und die Programme i.d.R. ein ganzes Stückchen schneller ablaufen (Faktor 2-4).
" ...

Damit ist C# .NET gegenüber Visual C++ 6.0 gemeint. Folglich ist auch C++ .NET langsamer als Programme ohne .NET (gleiches Framework, gleiche Klassen, gleiche Funktionen).

Darüber hinaus findet man z.B. auf:

http://www.edv-buchversand.de/mspress/

(Microsoft verkauft hier Bücher), wenn man Bücher zum Thema "C++ .NET" mit z.B. "Visual Basic .NET" (oder C#) vergleicht fast nur Bücher zu Visual Basic .NET oder C#.

Es scheint so, dass "C++ .NET" eine Totgeburt ist.

[Fallen]

Nope ganz und gar nicht, ich nehme jezt an das ich unter C++ .Net Managed C++ verstehen kann.

Das Managed C++ eine wirkliche Schande was Performance etc angeht kann ich bestätigen zumindest sind meine Erfahrungen so, der Code ist unübersichtlich und löst kronische Brechreize aus, aber um zB C++ Wrapper für C# zu schreiben ist es eine wirklich feine Sache da man die in managed C++ generierten Assemblies wirklich schön in C# einbinden kann. Habe dies einige male gebraucht auch wenn es mir Schmerzen bereitete.

Für Arbeiten in denen Windowselemente benötigt werden nutze ich wenn ich auf einige C++/C Dinge nicht verzichten kann auch Managed C++, wenn es sich aber vermeiden lässt nutze ich aber dennoch lieber C#.

Daher gelten folgende Dinge für mich:

Vorteil Managed C++:
- Ideal um reine C++/C Angelegenheiten für C# umzusetzen
- Windowscontrols in Verbindung mit C++/C Angelegenheiten

Nachteil Managed C++:
- Hässlicher Code
- Lahm
- einige Elemente sind nicht wirklich durchdacht (C# zu Managed Portierung)

Wenn es geht würde ich schon C# nehmen wollen ad sich dies nicht wirklich in Sachen Performance verstecken braucht (siehe ArenaWars welches komplett in C# geschrieben wurde). Eine Totgeburt ist Managed C++ deshalb aber nicht. (aber nahe dran)
_________________
"I have a Core2Quad at 3.2GHz, 4GB of RAM at 1066 and an Nvidia 8800 GTS 512 on Vista64 and this game runs like ass whereas everything else I own runs like melted butter over a smokin' hot 18 year old catholic schoolgirl's arse."