PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : DirectX 9


Einfachkrank
2003-02-02, 20:14:55
Hey,

hat schon jemand von euch sich das neue DirectX 9 SKD unter die Lupe genommen? Kann mir vielleicht jemand in ein paar kurzen Sätzen sagen, was sich von 8.1er geändert hat und obs irgendwie leichter geworden ist? Weil im Gegensatz zu OpenGL war DirectX immer ziemlich umfangreich (so kam es mir zumindest immer vor :D). Denn da ich demnächst mal ein kleines Projekt starten wollte, würde es mich mal interessieren, ob es sich lohnt, sich noch mal DirectX 9 anzuschauen, bevor ich mich auf OpenGL festlege...

MFG Einfachkrank

Demirug
2003-02-02, 20:29:07
Viel geändert hat sich nicht.

-Die Shaderverwaltung wurde von Handels auf Objekte umgestellt.
-Die neuen Shaderversionen 2.0 2.0+ und 3.0 wurden hinzugefügt.
-Das Binden der Vertexströme an einen Vertexshader ist jetzt flexibler geworden.
-Das Texture-Sampler und Stage Setup wurden getrennt
-Es gibt ein paar neue Renderstates

Das dürfte es im wesentlichen sein.

Einfacher geworden ist es eigentlich nicht.

Einfachkrank
2003-02-02, 21:26:25
Mmhhh... ich werd wahrscheinlich trotzdem mirs nochmal ansehen. Aber wenn wir gerade dabei sind - was machtn genau en Shader? Und wo verwendet man die? Ich hab die bis jetzt noch nie benutzt.

Demirug
2003-02-02, 22:14:42
Originally posted by Einfachkrank
Mmhhh... ich werd wahrscheinlich trotzdem mirs nochmal ansehen. Aber wenn wir gerade dabei sind - was machtn genau en Shader? Und wo verwendet man die? Ich hab die bis jetzt noch nie benutzt.

Es gibt in DirectX (in OpenGL auch dazu gleich mehr) zwei Arten von Shadern Vertex und Pixelshader.

Ein Vertexshader hat nun die Aufgabe aus bis zu 16*4 Float Werten pro Vertex die für das Trisetup benötigten Werte zu berechnen. Das ist mindestens die vollständige Position (x,y,z und w). Zusätzliche können noch 2 Farbwerte, 8 Texturkoordinaten, 1 Fogwert und die Punktgrösse berechnet werden. Ein solches Programm besteht aus einfachen Assemberartigen Anweisungen. Neben den Eingangswerten stehen noch zusätzlich Konstanten und Temp-Register zur verfügung. Die Temp-Register haben immer nur für ein Vertex Gültigkeit. Die Konstanten können nur pro Primitive geändert werden.

Ein Pixelshader bekommt nun für jedes zu berechnen Sample (wichtig wegen MSAA vs SSAA) vom Trisetup die interpolierten Farb (max 2) und Texturkoordinaten (max 8) und muss damit die die entgültige Farbe bestimmen. Auch hier gibt es wieder verschiedene Assembler Befehle Temp sowie Konstanten-Register.

Mit aufsteigener Versionnummern der Shader gibt es mehr Möglichkeiten.

Der Sinn von Shadern liegt einfach eine höhrer Flexibilität im Vertex und Pixelprocessing.

Bei OpenGL gibt es ebenfalls Shader. Dort werden sie nur als Vertex und Fragmentprogramme bezeichnet. Bis vor kurzem gab es aber dafür nur Hersteller spezifische Extensions. Im Vertexbereich gibt es jetzt eine Herstellerneutrale extension welche in allen OpenGL Treibern für DX8 Karten vorhanden sein sollte. Für Fragmentprogramme gibt es derzeit wohl nur eine allgemeine Extension für FP-Fragmentprogramme was einen R300 oder NV30 Chip vorraussetzt.

Einfachkrank
2003-02-03, 13:07:33
Ahh, cool. Ehm, das is jetzt schon wieder so ne alte und mittlerweile nervige Frage, aber glaubt ihr, dass DirectX schneller als OpenGL ist? Mir kam das bis jetzt nicht so vor, aber bekomme ich immer wieder gesagt... :)

Demirug
2003-02-03, 13:43:29
Originally posted by Einfachkrank
Ahh, cool. Ehm, das is jetzt schon wieder so ne alte und mittlerweile nervige Frage, aber glaubt ihr, dass DirectX schneller als OpenGL ist? Mir kam das bis jetzt nicht so vor, aber bekomme ich immer wieder gesagt... :)

Mit dem schneller ist das so eine Sache. Gerade dabei spielen natürlich die Treiber eine nicht unerhebliche Rolle.

Bei OpenGL muss man nun sagen das es dort das gesamte Spektrum an Geschwindigkeiten gibt. So ist zum Beispiel der immediate mode (z.B. glBegin glEnd) zwar einfach zu Programmieren aber auch sehr langsam. Um nun bessere Performances zu erreichen muss man auf komplexere Verfahren zurückgreifen. Die beste Performance bieten in der Regel die Hersteller spezifischen Extensions. Da diese oft sehr genau auf den Chip zugeschnitten sind erreicht man damit auch oft eine bessere Performances als mit D3D.

DirectX als Spiele-API beinhaltet kaum Elemente die nicht schon von Grund auf auf Performances ausgelegt sind. Aus diesem Grund ist der Einstieg in D3D auch etwas schwieriger weil man sich gleich mit der auf Performances ausgelegten Schnittstelle auseinader setzen muss.

Zusammengefasst kann man sagen: OpenGL und D3D sind in etwa gleich schnell wenn man bei OpenGL die performanten Herstellerneutralen Funktionen benutzt. Dort kommt es im wesentlichen auf die Treiber an. Bei der Verwendung von Herstellerspezifischen Extensions kann man mit OpenGL aber durchaus noch ein bischen mehr rausholen.

Das bei vielen Spielen welche sowohl OpenGL und D3D anbieten die OpenGL Variante schneller ist liegt primär an zwei Dingen.

Viele dieser Engines haben immer noch einen Ursprung in einer Glide tauglichen Engine. Glide läst sich nun aber viel einfacher in OpenGL umändern als in DirectX.

Engines welche multiple Render-APIs unterschützen müssen ja selbst wiederrum eine API definieren. Die API wird dann in die verschiedenen 3D-APIs (OpenGL, D3D, ...) umgemapt. Je kleiner der unterschied zwischen der Engine-API und der 3D-API ist desto weniger Performances geht verloren. Da bei solchen multi Engine oft zuerst der OpenGL teil programmiert ist die Engine-API nicht selten auf OpenGL besser als auf andere APIs zugeschnitten.

zeckensack
2003-02-03, 19:46:08
Bisserl neben dem Thema, aber nett:
John Carmack hat in seinem letzten .plan Update durchblicken lassen, daß ARB_vertex_array_object kurz vor der Fertigstellung steht.
Das heißt dann, daß es in Kürze endlich eine einheitliche Methode für optimalen Geometrietransfer geben wird.

Dann bleiben als relevante 'Schwäche' eigentlich nur noch Fragment Shader. Da muß man sich unterhalb des PS2.0-Levels immer noch mit mehreren Spezialfällen herumschlagen.

Einfachkrank
2003-02-04, 17:08:38
Hi,

Gibt`s Veränderungen was die Initialisierung von Direct3D oder die Enumeration betrifft? Wenn ja, gibt`s schon en gutes Tutorial dazu?

MFG Einfachkrank

Demirug
2003-02-04, 17:22:52
Originally posted by Einfachkrank
Hi,

Gibt`s Veränderungen was die Initialisierung von Direct3D oder die Enumeration betrifft? Wenn ja, gibt`s schon en gutes Tutorial dazu?

MFG Einfachkrank

Ist im Prinzip genauso wie bei DX8. Es sind aber beim SDK sowieso wieder die Tutorials für die ersten Schritte dabei. Mit denen ich ich eigentlich immer gut klargekommen.

Einfachkrank
2003-02-04, 19:19:15
passt jetzt hier eigentlich nicht, aber es war mal kurz die Rede von den Extensions von OpenGL - was gibt´sn da für welche? Multitexturing is doch eins, oder?

Xmas
2003-02-04, 19:28:38
Originally posted by Einfachkrank
passt jetzt hier eigentlich nicht, aber es war mal kurz die Rede von den Extensions von OpenGL - was gibt´sn da für welche? Multitexturing is doch eins, oder?
Es gibt fast 300 Extensions, siehe hier (http://oss.sgi.com/projects/ogl-sample/registry/).

Allerdings sind einige davon schon Bestandteil der aktuellen OpenGL Base-Specs, so auch das Multitexturing.

Einfachkrank
2003-02-04, 19:51:39
:O boah, was gehtn?! Das is schon ne ganz schöne Liste! Also schätze ich mal,dass es bei OpenGL auch so was wie Enumeration gibt, oder? Das man spezieller die Grafikkarte programmiertechnisch herausbekommt, und so etwas mehr Leistung bekommt, oder?

Demirug
2003-02-04, 19:58:47
Man kann sich vom OpenGL Treiber eine Liste mit allen unterstützten Extension geben.

http://www.cs.rit.edu/~ncs/Courses/570/UserGuide/OpenGLonWin-17.html

zeckensack
2003-02-04, 19:58:55
Die Liste wird seit 1991 geführt, vieles davon brauchst du mit aktuellen Treibern nicht zu beachten.

Schau mal in die GL-Spezifikation unter 'Corollaries', das sind schlappe 40 (!) Seiten, die alle Extensions auflisten die bisher in die Kernspezifikation aufgenommen wurden.

Enumeration gibt's bei OpenGL nicht, IMO ist das auch gut so (siehe Nasenbaer's Thread).
glGetString(GL_EXTENSIONS) liefert einen Zeiger auf einen C-String (char[] halt), der alle unterstützten Extensions auflistet. Vieeeeel einfacher.

zeckensack
2003-02-04, 20:00:21
Originally posted by Demirug
Man kann sich vom OpenGL Treiber eine Liste mit allen unterstützten Extension geben.

http://www.cs.rit.edu/~ncs/Courses/570/UserGuide/OpenGLonWin-17.html Japp :)

Und man kann sich anschauen, welche Karte was unterstützt:
http://www.delphi3d.net/hardware/index.php

Xmas
2003-02-04, 20:52:31
Originally posted by zeckensack
Enumeration gibt's bei OpenGL nicht, IMO ist das auch gut so (siehe Nasenbaer's Thread).
glGetString(GL_EXTENSIONS) liefert einen Zeiger auf einen C-String (char[] halt), der alle unterstützten Extensions auflistet. Vieeeeel einfacher.
Also IMHO könnte es noch viel einfacher sein wenn es einfach eine Funtion glIsExtensionSupported() gäbe. Sowas muss man sich dann eben selbst schreiben. Zumal es ja nicht nur einen Extensions-String gibt :bonk:

Außerden wäre es schön gewesen, wenn für jede Extension eine struct mit den entsprechenden Funktionspointern und Konstanten definiert worden wäre, die man mit z.B. glGetExtensionStruct("Name der Extension", Pointer auf struct) abfragen könnte. Für jede Funktion wglGetProcAddress() ist schon nervig.