DirectX 11 Jumpstart: Die Konfiguration der IDE

Die Einstiegshürde für DirectX 11 ist deutlich höher als die von XNA und daher fällt die Entscheidung für Neulinge oft eindeutig aus: XNA gewinnt, da man sich gerade am Anfang wenn man sowieso schon überwältigt ist von allem was da auf einen zukommt, deutlich weniger Probleme einhandeln möchte und möglichst schnell Ergebnisse erzielen möchte. Trotzdem möchte ich an dieser Stelle die Gelegenheit nutzen und einen Einblick in DirectX ermöglichen und versuchen den Einstieg schnell und einfach zu ermöglichen.

Die Frage ist hier natürlich: Warum DirectX und warum Version 11? Dies sind berechtigte Fragen auf die ich selbstverständlich auch eine Antwort habe. Aktuelle Empfehlung von Microsoft zur Erstellung von „Metro Style Games“ ist DirectX/C++. Da Windows 8 DirectX 11.1 verwendet bietet es sich an diese Version zu verwenden. Da nicht jeder die Developer Preview installieren kann oder will werde ich zunächst mit DirectX 11 beginnen. Die neuen Features von DirectX 11.1 benötigen wir erstmal nicht, daher reicht DX11 vollkommen aus und die grundsätzlichen Unterschiede zwischen einem DX11/Win7 und einem DX11.1/Metro Style Game liegen hauptsächlich beim erzeugen der sogenannten Swap Chain und dem Render-Window.

Und warum „Metro Style Games“, wo doch Windows 8 auch XNA und andere Grafikbibliotheken unterstützen wird? Auch hierauf ist die Antwort schnell gegeben: Metro und der Windows 8 Kernel wird sich zukünftig sehr wahrscheinlich auf allen Geräten und Geräteklassen wiederfinden: Egal ob Desktop-PC, Slate, Tablet oder Notebook, auch auf dem Windows Phone („Apollo“) wird es wohl bald soweit sein und auch um die XBox vNext ranken Gerüchte, dass diese auf dem Windows Kernel basieren könnte. Eine Umgebung und eine Sprache also für alle Geräte, solange diese unter Windows 8 laufen und das spart uns Arbeit, wenn wir Spiele für alle Systeme anbieten wollen.

Genug der einleitenden Worte es gibt gute Gründe für DirectX und C++ und wir können daran nichts ändern, so schade wir das auch finden mögen. Wir können es also verwenden oder auch nicht und wer jetzt weiterliest, der möchte es zumindest ausprobieren.

Wir benötigen Software

Bevor wir loslegen können benötigen wir ein wenig Software und die gute Nachricht ist, dass Microsoft uns hier kostenlos mit extrem guter Software versorgt.

Fangen wir mit der IDE, also dem Integrated Development Environment (integrierte Entwicklungsumgebung) an. Ich werde für meine Artikel Visual Studio 2010 verwenden. Ein ähnliches Vorgehen ist jedoch auch mit neueren Versionen möglich. Downloaden könnt ihr die IDE auf der eigens von Microsoft eingerichteten Microsite zu Visual Studio Express. Dort laden wir aus der Kategorie Windows Visual C++ 2010 Express herunter und installieren dieses. Wer Schüler oder Student ist bekommt über seine Schule unter Umständen eine kostenfreie Versionen zum lernen im Rahmen des Dreamspark-Programm bereitgestellt. Die Express-Version reicht aber vollkommen aus.

Während die Installation läuft können wir uns um die zweite notwendige Software kümmern: Das DirectX SDK. SDK steht für Software Development Kit und enthält eine Reihe von Libraries, als auch Header-Dateien. Abgerundet wird das alles von Beispielen, Tools und einem Haufen Dokumentation. Die aktuelleste Version ist das Juni 2010 SDK und gleichzeitig wird dies auch die letzte Version sein. Zukünftig ist das DirectX SDK in das Windows SDK integriert und muss nicht mehr separat beschafft werden. Ob dies ein Vorteil oder ein Nachteil sein wird, darüber möchte ich mich an dieser Stelle nicht auslassen. Dies wird die Zukunft zeigen.

Während Download und Installation laufen können wir schnell einen Kaffee trinken gehen oder so. Immerhin handelt es sich um etwas mehr als 500MB. Nachdem dieser Punkt erledigt ist gehen wir über zum nächsten Punkt:

Die Einrichtung

Wir starten nun das frisch installierte Visual Studio 2010 und richten es ein. Als erstes erzeugen wir dafür ein neues Win32 Projekt, welches wir durch Klicken auf Datei/Neu/Projekt erstellen. Bevor der Assistent durch einen Klick auf OK gestartet wird, müssen wir dem Projekt natürlich einen Namen geben. Ich habe dafür Tutorial01 gewählt. Auf der zweiten Seite wählen wir leeres Projekt und klicken auf Fertigstellen.

Wir haben nun ein leeres C++-Projekt das wir nun weiter konfigurieren werden.

Aus dem Ansicht-Menü rufen wir nun unter weitere Fenster den Eigenschaften-Manager auf. Dieser öffnet sich etwas versteckt im rechten Bereich.

Im vorherigen Screenshot habe ich den folgenden Schritt bereits vorgenommen. Ihr klickt den Baum einfach solange auf, bis ihr den Eintrag „Microsoft.Cpp.Win32.user“ unter eurem Projekt findet. Auf diesen Eintrag macht ihr nun einen Doppelklick was dazu führt, dass ein neues Fenster geöffnet wird.

Im linken Bereich wählt ihr nun „VC++ Directories“, da wir dort ein paar Änderungen vornehmen müssen.

Zunächst erweitern wir die Liste der Includeverzeichnisse. Klickt mit der linken Maustaste auf die entsprechende Zeile im rechten Bereich des Fensters. Am Ende der Zeile erscheint nun ein kleiner Pfeil, der nach unten gerichtet ist. Dieser muss nun ebenfalls angeklickt werden und dann wählt ihr im Menü das sich öffnet den Punkt Bearbeiten aus.

Nun klickt ihr auf das kleine Ordner-Symbol mit dem Stern. Der Tooltip beschreibt das Symbol mit Neue Zeile. Alternativ könnt ihr auch Strg + Einfügen drücken. Der Cursor landet nun in einer neuen Textbox in den ihr den Pfad eingeben könnt. Wer den Pfad nicht auswendig kennt, der klickt einfach auf den Button mit den drei Punkten am Ende der Zeile und wählt den Pfad mit einem der von Windows bekannten Verzeichnis-Auswahl-Dialoge aus.

Das Verzeichnis das ihr hier auswählen müsst ist im DirectX-SDK-Verzeichnis zu finden. Dieses befindet sich in der Regel unter C:\Program Files (x86) und heisst Microsoft DirectX SDK (June 2010). Als vollständigen Pfad fügen wir also

C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Include

hinzu.

Ein Bibliotheksverzeichnis benötigen wir ebenfalls. Wir gehen so vor wie bereits beschrieben, wählen aber anstatt dem Include-Verzeichnis aus dem DirectX-SDK das lib-Verzeichnis aus. Zunächst beschränken wir uns (auch auf einem 64Bit-System) auf die 32Bit-Variante von DirectX. Daher wählen wir auch das Unterverzeichnis x86 aus.

Wir können das Fenster nun mit OK schliessen. Ab jetzt sollten in diesem und auch in allen neuen Win32-Projekten DirectX-Programme problemlos kompilieren. Wir haben dies als Voreinstellung für alle zukünftigen Projekte eingestellt. Das klingt jetzt erstmal ziemlich kompliziert und nach ziemlich viel Arbeit für ein sehr kleines Ergebnis. Das ist es grundsätzlich auch, aber kompliziert ist es zumindest nicht wirklich und ausserdem müssen wir das nur einmal machen. Wenn man den Hintergrund kennt und weis, was da passiert, wird auch schnell klar was dort passiert und es ist dann auch nicht mehr weiter kompliziert und geht fast automatisch von der Hand. Und genau das möchte ich euch zum Abschluss noch kurz näher bringen.

Der C++-Compiler erzeugt beim Kompilieren sogenannte Objektdateien. Dies sind in Maschinensprache kompilierte Module mit Funktionen. Mehrere dieser Module können zu Funktionsbibliotheken zusammengefasst werden und der Linker fügt diese Programmteile dann zu unserem Programm hinzu, wenn diese benötigt werden. Dies ist meist der letzte Schritt der Kompilierung.

Um nun eine Beschreibung dieser vorkompilierten Funktionsbibliotheken zu haben gibt es die sogenannten Header-Dateien (Endung .h). Diese enthalten die Beschreibung dessen, was in der Bibliothek enthalten ist. Dabei handelt es sich nur um Klassendefinitionen und Funktionsköpfe, normalerweise aber nicht um ausführbaren Code (es gibt Ausnahmen, aber die sind für das generelle Verständnis erstmal nicht weiter wichtig).

Wir müssen also zwei Schritte machen um eine Bibliothek zu verwenden:

1. Header-Datei einbinden
2. Library linken

Beides übernimmt der Compiler für uns, aber wir müssen ihn dabei ein klein wenig unterstützen. Zum einen muss dem Compiler natürlich mitgeteilt werden wo er nach Headern und Libraries suchen soll und wir müssen die notwendigen Header in unseren Source-Code inkludieren. Den ersten Schritt haben wir in diesem Artikel gemacht, den zweiten Schritt lernen wir in den weiteren Teilen dieser Artikelreihe kennen. Da wir mit DirectX arbeiten wollen haben wir die entsprechenden Verzeichnisse aus dem DirectX-SDK referenziert und damit stehen uns die Header und Libraries von DirectX nun zur Verfügung.

Es gibt übrigens zwei Arten von Libraries: statische und dynamische. Die dynamischen sind sogenannte DLLs (so werden die Dynamic Link Libraries unter Windows genannt). Diese sind vergleichbar mit .NET-Assemblies. Die Library wird vom Betriebssystem geladen wenn sie benötigt wird und die Einsprungadressen werden automatisch so umgebogen, dass die richtigen Funktionen aufgerufen werden.

Beim statischen Linken werden die Libraries an unser Programm angehangen. Augenscheinlicher Vorteil ist, dass danach nur noch eine Datei vorhanden ist und eine .DLL-Datei nicht mehr notwendig ist. Der Nachteil dabei ist aber, dass das ausführbare Programm größer wird und damit auch die Ladezeiten und der Speicherverbrauch.

Beide Arten von Libraries haben eine Daseinsberechtigung. Auf die Details möchte ich hier jetzt nicht näher eingehen, wichtig ist nur, dass ihr beide Varianten kennt und schon mal davon gehört habt. Dies ist für das Verständnis wichtig und bietet eine gute Grundlage für weitere Arbeiten.

Zusammenfassung und Abschluss

In diesem kurzen Artikel haben wir gemeinsam die Entwicklungsumgebung installiert und alles soweit vorbereitet, dass wir im nächsten Schritt unser erstes DirectX-Programm entwickeln können. Wir haben ein paar Informationen über Libraries erhalten und wissen nun, was ein Linker ist.

Wir haben festgestellt, dass die Welt unter C++ und nativem DirectX deutlich komplizierter und arbeitsintensiver ist als zum Beispiel mit XNA und C#. Der Lohn für diese Mühe ist jedoch eine deutlich höhere Flexibilität und in einigen Fällen auch eine deutlich höhere Geschwindigkeit.

Ich hoffe, dass ich mit dem Beginn dieser neuen Artikelreihe das Interesse vom ein oder anderen Leser wecken konnte und freue mich schon euch im nächsten Teil wieder begrüßen zu dürfen.

Advertisements

Veröffentlicht am 06.02.2012 in DirectX, DirectX 11, Grundlagen und mit , , , , , getaggt. Setze ein Lesezeichen auf den Permalink. 14 Kommentare.

  1. Ich finds super, dass Du auch mal was über DirectX machst. Bisher bin ich vor C++ immer zurückgeschreckt, da es mir bei dem bisschen Erfahrung, was ich damit gesammelt habe, immer sehr kompliziert vorkam (unter anderem hatte ich häufig das Problem, dass eine Funktion z.B. wchar_t zurückgegeben hat, ich aber char brauchte und anders herum, das musste dann immer erst mit einer Weile Googlen gelöst werden…) Ich bin aber soweit zuversichtlich, dass Du es mal wieder schaffen wirst Licht ins Dunkle zu bringen ;D

  2. Aloha,
    ich finde es sehr schön, dass du nun in deinem Blog auch ein wenig über C++ und vor allem DX11 schreibst. Ich habe in den letzten Monaten festgestellt, dass ich mit C++ und DX11 wesentlich besser zurecht komme als mit XNA. Zumindest was die Qualtität der Ergebnisse betrifft. Dies liegt sicher daran, dass man sich mehr mit den Hintergrunden beschäftigen muss.

    Nun habe ich jedoch noch eine kleine Ergänzung für deinen Artikel, der vorallem bei allen Leuten mit mehreren Rechnern oder die im team arbeiten wollen hilfreich sein sollte:
    Wenn man das DXSDK über dne Installer installiert, dann legt es automatisch eine PATH-Variable in Windows ab. Diese kann man dann als Pfad bei den „C++ – Verzeichnissen“ nutzen. Das hat den Vorteil, das man beim portieren des VS-Projektes auf einen anderen PC (SVN, USB, etc) nicht jedes mal die Pfade anpassen muss, wenn die Installationspfade vom SDK sich unterscheiden (beispielweise installiere ich bei mir alle SDKs in einen extra SDK-Ordner).
    Die Pfade sehen bei mir dann so aus:
    $(DXSDK_DIR)\Include
    $(DXSDK_DIR)\Lib\x86

    Zuletzt hätte ich noch ein paar Anregungen und Wünsche an deine folgenden Artikel:

    1.) Es wäre super, wenn du auf das von David genannte Problem bereits im Vorfeld eingehen könntest. Bei meiner Engine hat es mich ziemlich viel Arbeit gekostet, dass Windows/DX-Methoden fast nur mit wchar_t arbeiten, man aber intuitiv immer char verwendet (meine Engine nutzt intern momentan nur wchar_t, allerdings per Makro definiert).

    2.) Wenn du zum Objekte laden kommst, wäre es klasse direkt mit .obj und .mtl Files zu beginnen. Mit .x oder gar einem eigenen Format zu arbeiten, bringt einem nach meiner Erfahrung nur Probleme, wenn man nicht direkt mit einem echt guten Konzept rangeht (wie eigene Fileeditoren/Konverter).

    Freue mich schon auf mehr!
    mfg
    Neo

    • Sehr guter Tipp, danke sehr 🙂

      Zu den beiden Punkten: Werde ich mir notieren und darauf entsprechend eingehen. Insbesondere zum zweiten Punkt habe ich einen vielleicht interessanten Ansatz, aber mehr wird noch nicht verraten 😉

    • Bei mir kam, wenn ich nicht die PATH-Variable genutzt habe die Fehlermeldung, dass die d3dx11.lib Datei nicht geladen werden konnte!

  3. uhsadouiashduiohas

    Erstmal vorweg: Super Artikel und allgemein ist die Qualität dieses Blogs sehr hoch!

    was ich jedoch nicht verstehen kann, warum man sich als Entwickler immer an das hällt was MS vorgibt.
    In diesem Blog schreibt jemand der sich lange Zeit mit C# und XNA beschäftigt hat und das auch sehr gut beherscht. Jetzt kommt MS her und sagt, es wird in C++ programmiert und dann wird das einfach so hingenommen? ohne einen einzigen Kommentar?
    Das ist doch Mist. Es ist doch offentsichtlich dass das Konzept „ein OS für alle Geräte“ nicht aufgehen kann. Zumindest weiß das jeder der die Developer Preview benutzt hat. So lang man dafür entwickelt setzt sich das auch durch obwohls eigendlich niemand will. Als Entwickler hat man es in der Hand welche Platform sich durchsetzt und welche nicht. Noch viel schlimmer…man unterstützt dadurch ja implizit diverse andere Dinge die sich MS hier leistet (Stuchwort: secureboot).
    Man hat jetzt 2 Möglichkeiten:
    – man bleibt bei XNA und verliert Kunden aber macht eben das was man schon gut kann (C#/XNA) und behält seinen Stolz weil man weiß das ein so großes UNternehmen keine Macht über einen hat.
    – oder man lernt C++, hat enorm viel Portierungsaufwand, aber dafür hat man eine große Kundenbasis um seine kapitalistische Wertschöpfung zu erhöhen.

    Ich finde das einfach so krass das diese Sache von MS einfach so geduldet wird und mit keinem einzigen Wort hier erwähnt wird.
    Was MS sagt ist scheinbar Gesetz.

    und wenn man nochmal genauer drüber nach denkt:
    man nutzt nativen machinencode um Software zu schreiben die auf 3 Architekturen und 5 verschiedenen Eingabeparadigmen laufen soll? Gerade dafür ist doch managed Code gemacht, warum wird das jetzt weggeschmissen? Man hätte doch nur XNA eine Toucheingabe spendieren müssen und einen ARM Port schreiben und vl auch mal DX11 nachreichen müssen. Das ganze riecht doch danach das es sich nicht durchsetzt.
    Bei Android regen sich die entwickler auf, das es zu sehr fragmentiert ist und das man seine Software auf verschiedenen OS-Versionen testen muss. Hier geht es nicht um OS-Versionen sondern direkt um 3 verschieden Architekturen (ich denke mal nicht das MS bei der xbox auf x86 setzten wird) und 5 verschiedene Gerätekategorien (handys mit kleinem Bildschirm, tablets mit großen bildschirm, desktops mit maus und tastaur, konsolen mit gamepad und bewegunssteuerung, laptops). Bei Android sieht man ja schon das Entwickler das blöde finden, hier wird es komplizierter und man weiß es auch noch vorher schon und nimmt es trotzdem einfach hin 😦

    Mein Traum eines über Jahre hinweg leeren MetroStore’s ist wohl geplatzt da es jetzt schon einen Entwickler gibt, der dafür entwickeln wird. 😦

    gruß

    • Ein langer Kommentar, der auch eine lange Antwort verdient hat 🙂

      Wenn du meinen Blog aufmerksam verfolgt hättest, dann wüsstest du, dass ich schon vor einiger Zeit etwas über das Thema geschrieben habe und mit dem ANX.Framework auch ein Projekt gestartet habe, dass diesen „Misstand“ beheben soll. Auf der anderen Seite muss ich dir aber (und zwar aus Überzeugung) in einigen Punkten wiedersprechen. Warum sollte das Konzept „OS für alle Geräte“ nicht aufgehen? Es dürfte sogar wunderbar aufgehen.

      Erstmal zum „Desktop-Windows8“: Alle haben sich aufgrund einer PREVIEW darauf eingeschossen, dass dieses OS aufgrund der Oberfläche nicht für Desktop-PCs geeignet wäre. Dazu kann ich nur sagen: Ich finde das „neue“ Startmenü, dass übrigens OPTIONAL ist gut geeignet. Ich habe auf meinem Rechner zwar locker 100 Programme, aber davon benutze ich eigentlich ziemlich genau 6 oder 7 auf täglicher Basis und diese Programme machen 90% meiner Beschäftigung an meinem Rechner aus. Diese habe ich mir an die Taskleiste gepinnt und damit muss ich praktisch nie mehr das Startmenü öffnen. Für mich nicht viel umgewöhnung 😉 Für andere auch nicht. Durch die von Windows (auf freiwilliger Basis) gesammelten Telemetriedaten hat Microsoft eine ziemlich genaue Übersicht darüber wie Windows verwendet wird. Sicherlich gibt es eine Reihe von Leuten die das anders machen, aber es ist auch nicht gesagt, dass es keine Alternativen gibt. Wie gesagt -> Metro-Oberfläche ist optional.

      Das Programme gut sowohl auf Tablets, als auch auf Phones laufen hat iOS gezeigt und Android ebenfalls. Warum dann nicht noch der Desktop dazu? Viele Apps die auf dem Phone nützlich sind, sind auch auf dem PC nützlich und auf der „Multimedia-Zentrale“ XBox im Wohnzimmer auf dem Fernsehen ebenso.

      Zum Thema Secureboot: Auch dies ist optional. Willst du subventionierte Hardware kaufen? Dann musst du in den „sauren Apfel“ beissen, aber auch das ist kein Zwang. Wenn dir Secureboot nicht passt, dann kaufe dir einfach ein Gerät ohne Secureboot. Nirgendwo steht geschrieben, dass Windows 8 nur auf Geräten installiert werden kann, die Secureboot unterstützen. Dem ist nicht so. Und auch wenn es so wäre: Es zwingt dich ja niemand zu Windows 8…

      Zu C++: Sicherlich ist dies ein sehr schmerzhafter Schritt, weg von XNA, weg von C#, aber der Markt hat gezeigt, dass XNA deutlich weniger gut anzukommen scheint als einige es vielleicht wahr haben wollen. Ich habe vor XNA bereits mit C++ und DirectX gearbeitet und habe sogar lange nicht an XNA geglaubt. Trotzdem hatte ich eine tolle Zeit damit und habe sie auch weiterhin, aber C++ hat einige Vorteile. Bei mir war es nämlich so, dass ich viele, viele Stunden damit verbracht habe Wrapper zu schreiben (für Box2D und für Bullet-Physik) und für meine Scene-Manager und viele andere Dinge. Diese habe ich von C++ nach C# portiert und viele andere haben das auch gemacht. Sowas kann ich mir zukünftig sparen und viele andere auch. Und das ist genau der Punkt. Wenn ich C++ verwende, dann habe ich alles an Libraries was das Herz begehrt im Überfluss. Und das nicht nur für „Windows-Geräte“ sondern auch noch für viele andere. Die Medaille hat immer zwei Seiten. Ausserdem ist noch nicht klar, dass XNA verschwinden wird. Ich denke, dass es sich verändern wird und in der ein oder andere Form zukünftig existieren wird, aber warum nicht neben C++/DirectX?

      Der Metro-Store wird nicht leer sein, denn alle Nicht-Game-Apps werden weiterhin laufen, sowohl unter Windows 8, als auch auf Tablets, dem Windows Phone und vielleicht sogar auf der XBox. Für Spiele wird es etwas anders aussehen, dafür wird es aber vielleicht zukünftig einen riesen Vorteil geben: Engines wie Ogre3D, Unity, Halflife oder Crytek werden auch wieder auf diesen Geräten laufen und damit neue Welten eröffnen. Sicherlich wird es für viele schwerer werden, insbesondere für Einsteiger… Aber wenn ich ehrlich bin: Ich habe die letzten 25 Jahre mit solchen Herausforderungen leben können und hatte eine schöne Zeit damit und werde es auch sicherlich die nächsten 25 Jahre können. Mit Microsoft, aber auch ohne…

      • uhsadouiashduiohas

        Warum sollte das Konzept “OS für alle Geräte” nicht aufgehen? Es dürfte sogar wunderbar aufgehen.

        Grundsätzlich habe ich von der Oberfläche geredet. Der Kernel ist jetzt mal nicht so interresant.
        Aber es liegt doch auf der Hand. Auf dem PC habe ich kein Touch. Auf dem Handy habe ich kein Platz für einen Desktop. Für was ist denn jetzt Metro gedacht? für Tablets ist es super. Für den PC Mist, da man die Toucheingaben nicht so sauber mit der Maus nachmachen kann…geschweige denn Multitouch. Für Handys ist Metro zu „grob“ und wie soll ich mit nem XBox Controller Multitouch machen? (OK, niemand weiß bisher wie die neue XBox bedient wird.)
        Gut, davon kann man jetzt halten was man will, das soll jetzt hier nicht das Thema sein

        Erstmal zum “Desktop-Windows8″: Alle haben sich aufgrund einer PREVIEW darauf eingeschossen, dass dieses OS aufgrund der Oberfläche nicht für Desktop-PCs geeignet wäre. Dazu kann ich nur sagen: Ich finde das “neue” Startmenü, dass übrigens OPTIONAL ist gut geeignet. Ich habe auf meinem Rechner zwar locker 100 Programme, aber davon benutze ich eigentlich ziemlich genau 6 oder 7 auf täglicher Basis und diese Programme machen 90% meiner Beschäftigung an meinem Rechner aus. Diese habe ich mir an die Taskleiste gepinnt und damit muss ich praktisch nie mehr das Startmenü öffnen. Für mich nicht viel umgewöhnung 😉 Für andere auch nicht. Durch die von Windows (auf freiwilliger Basis) gesammelten Telemetriedaten hat Microsoft eine ziemlich genaue Übersicht darüber wie Windows verwendet wird. Sicherlich gibt es eine Reihe von Leuten die das anders machen, aber es ist auch nicht gesagt, dass es keine Alternativen gibt. Wie gesagt -> Metro-Oberfläche ist optional.

        naja bloß weil es für dich kaum Umgewohnung ist, ist das für andere nicht auch so. Ich war nicht in der Lage die Developer Preview zu bedienen ohne laufend auf dem Metro schirm zu landen. Jetzt muss ich halt meine Arbeitsweiße ändern.
        So richtig optional sieht Metro nicht aus, aber ok warten wir mal die Beta ab.

        Das Programme gut sowohl auf Tablets, als auch auf Phones laufen hat iOS gezeigt und Android ebenfalls. Warum dann nicht noch der Desktop dazu? Viele Apps die auf dem Phone nützlich sind, sind auch auf dem PC nützlich und auf der “Multimedia-Zentrale” XBox im Wohnzimmer auf dem Fernsehen ebenso.

        Leider ist das nicht so einfach. Wie man an iOS und auch an Android sehen kann, gibt es immer wieder Telefon-Versionen und Tablet-Versionen. (Als Beispiel die nativen Mailapps)
        Das man als Entwickler für jedes Gerät eine eigene Oberfläche machen muss ist nicht das Problem. Jeder macht das und das funktioniert auch. Nur MS macht das nicht…gerade das OS ist doch das wichtigste und MS passt es einfahc nicht an die Geräte an. Apple nutzt auch überall den selben Kern, hat aber _trotzdem_ für handys, tables, settopboxen, PCs eigene Oberflächen (ok das sehr grob beschrieben 😉 )

        Zum Thema Secureboot: Auch dies ist optional. Willst du subventionierte Hardware kaufen? Dann musst du in den “sauren Apfel” beissen, aber auch das ist kein Zwang. Wenn dir Secureboot nicht passt, dann kaufe dir einfach ein Gerät ohne Secureboot. Nirgendwo steht geschrieben, dass Windows 8 nur auf Geräten installiert werden kann, die Secureboot unterstützen. Dem ist nicht so. Und auch wenn es so wäre: Es zwingt dich ja niemand zu Windows 8…

        naja wenn man so sieht.
        Wenn man offene Hardware will muss man wohl die android tablets nehmen, da kann man wenigstens noch installieren was man will.

        Zu C++: Sicherlich ist dies ein sehr schmerzhafter Schritt, weg von XNA, weg von C#, aber der Markt hat gezeigt, dass XNA deutlich weniger gut anzukommen scheint als einige es vielleicht wahr haben wollen. Ich habe vor XNA bereits mit C++ und DirectX gearbeitet und habe sogar lange nicht an XNA geglaubt. Trotzdem hatte ich eine tolle Zeit damit und habe sie auch weiterhin, aber C++ hat einige Vorteile. Bei mir war es nämlich so, dass ich viele, viele Stunden damit verbracht habe Wrapper zu schreiben (für Box2D und für Bullet-Physik) und für meine Scene-Manager und viele andere Dinge. Diese habe ich von C++ nach C# portiert und viele andere haben das auch gemacht. Sowas kann ich mir zukünftig sparen und viele andere auch. Und das ist genau der Punkt. Wenn ich C++ verwende, dann habe ich alles an Libraries was das Herz begehrt im Überfluss. Und das nicht nur für “Windows-Geräte” sondern auch noch für viele andere. Die Medaille hat immer zwei Seiten. Ausserdem ist noch nicht klar, dass XNA verschwinden wird. Ich denke, dass es sich verändern wird und in der ein oder andere Form zukünftig existieren wird, aber warum nicht neben C++/DirectX?

        Wenn MS sagen würde das man Metro Games mit XNA programmiert dann setzt es sich aber durch. Man hat schon ein fertiges Framework und schmeißt es einfach weg? Und den Aufwand hat wieder der Entwickler.
        Und wenn es sich mal durchsetzt hätte man auch genug Libraries.

        Mir gehts hier auch nicht wirklich um WIn8 und Metro und bla…davon kann jeder halten was er will. (Ich wollte keine Metro Diskussion losreißen 😉 )
        (Außerdem geht es hier ja um Games und nicht um App-Oberflächen)
        Mir geht es darum , das MS laufend irgendwas vorschreibt und man das einfach so hinnimmt ohne drübernachzudenken.

        Hier mal die 2 Alternativen:
        – man programmiert in C++
        – man muss sich ein game-framework zusammen suchen
        – man muss genau prüfen ob der Code auch auf wirklich jeder Architektur läuft unter allen Bedingungen (ich denke nicht, das ein PC die diversen CO-Prozessoren einer XBox hat)
        – man muss für x86 compilieren für den Desktop
        – man muss für ARM compilieren fürs Handy/Tablet
        – man muss für PPC compilieren für die XBox (auch die neue XBox wird wieder einen PPC drin haben)

        oder:
        – man programmiert in C# (eine modernere Sprache, welche aber nicht die Freiheit von C++ nimmt)
        – man compiliert für .NET

        das war doch vorher viel einfacher. Auch war .NET schon verfügbar für x86/PPC/ARM. MS müsste nur einfach ihr XNA aktuell halten…jetzt nimmt man dafür halt irgendne Middleware (es gibt ja genug Libraries 😉 )

        (oder bietet das Win8 SDK die ganzen „Helferlein“ die man von XNA kennt? Gameloop, Primitives, Animations, Effekts, …)

        Ich persönlich werde das nicht mitmachen. XNA war das letzte was mich auf der Microsoftplattform gehalten hat. Ehrlich gesagt kann ich mir eine Programmierweiße ohne Interfaces garnichtmehr vorstellen.

        Ich kann den Weg von MS einfach nicht nachvollziehen. Auch kann ich an der „neuen Art und Weiße“ keine Vorteile erkennen.

        Ich glaub das man hier sehr stark unterschätzt wie aufwändig es ist C++ Code für mehrere Architekturen lauffähig zu halten!

        Wenn man ganz böse ist, könnte man auch behaupten, das MS hier ihr Monopol ausnutzt und Entwickler zeugs aufzudrücken. Erst die ganze Welt von Windows abhängig machen und dann mir vorschreiben mit was ich meine Games programmieren muss 😉

      • Du vergisst bei deinem scheinbar sehr emotionalen Kommentar, dass C++ für die Spieleentwicklung bereits Jahrzehnte vor XNA existiert hat. Gleiches gilt auch für DirectX, zwar noch nicht so lange, aber auch schon sehr, sehr lange. Microsoft schreibt hier nichts vor. XNA ist eine Alternative, die sehr gut für Einsteiger geeignet ist. XNA (welches übrigens zu großen Teilen in C++ entwickelt wurde) ist leider vom etwas professionelleren Bereich nie richtig angenommen worden, sondern es kamen nur Beschwerden, dass XNA nur auf einer begrenzten Anzahl von „Microsoft-Geräten“ läuft und wenn man dafür entwickelt die Arbeit zweimal machen muss. Und im Endeffekt entscheidet doch der Spieler: Dem ist die Programmiersprache egal, er will Spiele. Und wenn es die Spiele „Dank XNA“ nicht für MS-Geräte gibt, dann geht er halt woanders hin…

        Übrigens: Für C++ gibt es für alles hunderte Alternativen. Es gibt z.B. mindestens 3-4 3D-Physik-Libraries, die teilweise bereits seit Jahrzehnten entwickelt und optimiert werden. Was gibt es da für C++? Gleiches gilt für 2D-Physik. Es gibt zwei drei Derivate von Box2D (Farseer, starLiGHT.Physik, Box2D.XNA) das in C++ entwickelt wurde. Ich hab in meine Variante hunderte Stunden Arbeit gesteckt um auf nahezu die gleiche Geschwindigkeit wie in C++ zu kommen und um diese eine Library mit XNA nutzen zu können. Bei jedem neuen Update entsteht teils wieder viel Arbeit. Unter C++ dauert das einbinden so ziemlich genau zwei Minuten.

        Nochmal zur Developer Preview: Diese wurde auf der Build-Konferenz vorgestellt. Dort hat jeder Entwickler ein Windows 8 Tablet erhalten um eine Möglichkeit zum entwickeln zu haben. Die Developer Preview soll die Unterschiede und Neuigkeiten aufzeigen, die Windows 8 bieten wird und das sind nunmal WinRT und die Metro Oberfläche. Und genau das kann man daran sehr gut erkennen. Ja, es ist für Touch-Eingabe ausgelegt, weil es auch für Touch-Geräte gedacht ist. Es ist echt interessant wie immer alle wissen, was Microsoft auf dem Desktop machen wird. Das wird frühestens klar werden, wenn die Public Beta Ende des Monats erscheinen wird…

      • uhsadouiashduiohas

        ich habe versucht in meiner Antwort ein paar Textblöcke zu zitieren. Leider hat WordPress hier meine Tags rausgelöscht.

        jetzt ist die Antwort ziemlich beschissen zu lesen 😉
        man kann nichtmehr außereinander halten was Kommentar und was Zitat ist.

        kannst dir des lesen also auch gleich sparen

  4. Wie immer ein qualitativ hochwertiger Blogeintrag, echt klasse!

    Mir stellt sich nun nur die Frage, weshalb du nirgendwo erwähnst (oder habe ich es überlesen?), dass man wohl bald auch mit C# Metro Apps entwickeln kann. SlimDX wird dies beispielsweise wohl bald unterstützen (http://www.gamedev.net/topic/619811-slimdx-and-win8-metro-apps/).
    Mir ist bewusst, dass C++ einige Vorteile in Sachen Performance, Plattformunabhängikeit und Einbindung von Middleware hat, aber in C# ist es mMn deutlich angenehmer und schneller zu entwickeln.

    Außerdem hatte ich irgendwo in Deinem Blog gelesen, dass du SharpDX SlimDX bevorzugen würdest. Weshalb? Ist es schneller/besser? Und wenn ja, wieviel schneller, ein Performanceunterschied von <1% ist nicht der Rede Wert, zumal SlimDX ja auch von erfahrenen Entwicklern schon einige Zeit programmiert wurde.

    Ansonsten danke im voraus und weiter so, der Blog ist echt super 🙂

    • Danke sehr, freut mich 🙂

      Ja, mit SlimDX ist es glaube ich sogar schon möglich Metro-Style-Games zu entwickeln, mit SharpDX ebenfalls seit einiger Zeit und just in diesem Moment mache ich Tests mit ANX auf einem frisch installierten Windows 8 (von wo ich gerade diesen Kommentar schreibe). Übrigens: Windows 8 ist um Welten schneller als Windows 7 😉

      Ich persönlich komme mit C# auch besser klar als mit C++, trotzdem sollte man doch hin und wieder mal über den Tellerrand hinausschauen, oder?

      Alexandre Mutel, der Entwickler von SharpDX verwendet eine spezielle Art und Weise des Interopens inkl. speziell optimiertem IL-Code und erzielt damit eine extrem hohe Geschwindigkeit. Natives DirectX wurde in umfangreichen Tests mit 1.0facher Geschwindigkeit bewertet. SharpDX liegt bei 1.52fache Geschwindigkeit, ist also gut 52 Prozentpunkte langsamer. SlimDX liegt bei ca. 2.50, also 150% langsamer und XNA liegt weit abgeschlagen bei fast 10.0facher Geschwindigkeit. Natives C++ ist also 10x schneller als XNA. Also schon extrem deutliche Unterschiede.

  5. Danke Glatzemann für einen Einstieg in C++ und Metro-Apps. Finde es klasse, dass du deinen Blog um diesen Themenbereich erweiterst.

  1. Pingback: DirectX 11 Jumpstart: Metro-Games für Einsteiger « "Mit ohne Haare"

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: