Archiv verlassen und diese Seite im Standarddesign anzeigen : Update DirectX Software Development Kit (SDK)
Features Added in the December 2005 DirectX SDK
The following features have changed or been added in the December 2005 DirectX SDK:
Direct3D 10 Technology Preview
Microsoft Cross-Platform Audio Creation Tool (XACT Beta)
Managed DirectX for .NET Framework 2.0 (Beta)
Windows Vista Game Explorer (Beta)
Redist
D3DX9
XInput
Tools
Samples
Technical Article Updates
http://msdn.microsoft.com/directx/sdk/
Zur info :wink:
Neomi
2005-12-15, 01:34:10
"This version of the DirectX SDK is not supported on this Operating System."
Verdammt, das Ding will sich unter Windows 2000 nicht installieren lassen, genau wie die Oktober-Version. Dabei steht diesmal Windows 2000 wieder mit auf der Liste der unterstützten Systeme. Kennt irgendjemand einen Weg, den Installer dazu zu überreden, 2000 auch tatsächlich zu unterstützen?
Eigentlich funktioniert das komplette SDK (wie auch das letzte) unter Windows 2000, bloß der Installer will nicht. Diese absichtliche Blockade ohne technischen Grund geht mir mächtig auf den Senkel. :mad:
Sehr krasse Spezifikation. Das ist wirklich ein gewaltiger Fortschritt.
OpenGL wird sicher wieder einige Jahre brauchen um da aufzuschließen.
ScottManDeath
2005-12-15, 06:39:52
Sehr krasse Spezifikation. Das ist wirklich ein gewaltiger Fortschritt.
Nice read, indeed. :)
OpenGL wird sicher wieder einige Jahre brauchen um da aufzuschließen.
:( Naja, muss mich dann mal aufraffen, richtig mit D3D anzufangen, eventuell dann gleich Managed. ;)
Demirug
2005-12-15, 07:25:15
Sehr krasse Spezifikation. Das ist wirklich ein gewaltiger Fortschritt.
Da sind durchaus ein paar Sachen die mir nicht unbedingt gefallen. Allerdings ist das ja auch nicht die Spec für die IHV. Es fehlen also noch ein paar Details. Wobei das auch nichts mehr an dem ändert was jetzt veröffentlicht wurde.
OpenGL wird sicher wieder einige Jahre brauchen um da aufzuschließen.
Da bin ich mir nicht so sicher. Da sie für D3D ein einheitliches Featureset anbieten müssen wird man sich auch schnell auf entsprechenden OpenGL Extensions einigen können.
Oblivion
2005-12-15, 12:03:31
Wäre wer so lieb und mir erklärn was da verändert wurde? blicke da net ganz durch
Ganon
2005-12-15, 12:09:18
OpenGL wird sicher wieder einige Jahre brauchen um da aufzuschließen.
Nö. M$ ist nicht mehr mit im Team, also geht's jetzt schneller. ;)
Da sind durchaus ein paar Sachen die mir nicht unbedingt gefallen.Was denn im Detail?
micki
2005-12-15, 13:39:39
soweit ich sehe, müssen alle das gleiche untersützen um dx10 zu supporten. das klingt sehr nach kgV. somit wird oGL wohl noch mehr features haben die nur dort vorhanden sind.
finde es auch dumm von ms, dass sie so kurz vor dx10 die xbox rausbringen, die nächsten 5 jahre werden spiele somit für dx9 und dx10 gemacht werden müssen, sodass der support für dx10 wohl meist nur ein aufklatsch sein wird... oder kann die xbox360 GS?
MfG
micki
Oblivion
2005-12-15, 14:44:17
finde es auch dumm von ms, dass sie so kurz vor dx10 die xbox rausbringen, die nächsten 5 jahre werden spiele somit für dx9 und dx10 gemacht werden müssen, sodass der support für dx10 wohl meist nur ein aufklatsch sein wird
Also dem kann ich nicht ganz folgen ...
soweit ich sehe, müssen alle das gleiche untersützen um dx10 zu supporten. das klingt sehr nach kgV. somit wird oGL wohl noch mehr features haben die nur dort vorhanden sind.Die Spielenentwickler interessiert nur das kgV. Es lohnt auch nicht mehr zu implementieren. Erstens ist man mit DX10 erstmal gut genug beschäftigt alles überhaupt auf den Chip zu packen und zweitens interessiert "keine Sau" mehr OpenGL außer Carmack, der auch schon signalisiert auf DX10 umzuschwenken.
micki
2005-12-15, 16:32:28
Also dem kann ich nicht ganz folgen ...
naja, wenn ich das richtig gesehen habe, gibt es keine caps. das bedeutet, dass es keine anpassungen für ein spiel geben muss für spezielle grakas. wenn man ein spiel für dx10 hat und die graka dx10 supportet, dann läuft es (in unserer schönen heilen welt). quasi wie bei einer konsole.
aber die xbox360 ist afaik dx9, das heißt: man wird doch noch zumindestens zwei versionen eines spieles machen müssen, denn durch einmal kompilieren ist es nicht getan.
die nächsten 5jahre wird man sich also mit technologie rumärgern müssen die heute eigentlich schon vom featureset durchschnitt ist.
als die erste xbox rauskam war sie vom featureset eigentlich noch highend. die gf3 war raus und die gf4 noch nicht. und noch ne lange zeit war dx8 somit aktuell. wir haben dx9 und die xbox wird abgelöst werden.
Die xbox360 ist erst kurz draussen und schon gibt es dx10. auch wenn die lebenszycles länger werden, es ist schon zu erwarten, dass dx11 ne zeitlang mit der dx9 xbox zusammenleben muss und zwischen dx8<->dx9 sind nicht solche welten wie dx9<->dx10.
naja, vielleicht überseh ich da was.
grandmasterw
2005-12-15, 16:34:23
Hohoho.. keine Sau. Also an der Uni ist OpenGL Standard. Wer will, kann auch DirectX für seine Progs verwenden, aber beigebracht wird einem OpenGL. Auch als Windows-Benutzer sollte man sich eben bewusst sein, dass nicht alles von MS sein muss. Und genauso, wie viele Leute aus Prinzip nie selbst ein wmv encoden würden, verwenden viele leute lieber OpenGL. Klar das Featureset war teilweise weit hinten, aber meist sind das Features, die eh fast keiner verwendet.
micki
2005-12-15, 16:35:53
Die Spielenentwickler interessiert nur das kgV.
diese pauschalisierung ist IMHO nicht zutreffend bei den meisten.
Es lohnt auch nicht mehr zu implementieren.
grahpic wird als wichtigstes marketing mittel gesehen und gerade da sind USP wichtige argumente, deswegen ist das extrem wichtig so ein alleinstellungsmerkmal zu haben.
zweitens interessiert "keine Sau" mehr OpenGL außer Carmack, der auch schon signalisiert auf DX10 umzuschwenken.
viele die dann lieber auf ps3 portieren wollen werden, wird oGL mehr als d3d interresieren.
MfG
micki
diese pauschalisierung ist IMHO nicht zutreffend bei den meisten.So? Welche Spiele der letzten Jahre außer Splinter Cell und Far Cry boten denn etwas was nur auf bestimmten Karten funktionierte? PS3.0 wurde nicht verwendet weil es nicht alle Karten konnten, genauso wie PS1.4 damals.
grahpic wird als wichtigstes marketing mittel gesehen und gerade da sind USP wichtige argumente, deswegen ist das extrem wichtig so ein alleinstellungsmerkmal zu haben.DX10 ist praktisch Feature-Complete, da gibts nicht viel zu erweitern.
viele die dann lieber auf ps3 portieren wollen werden, wird oGL mehr als d3d interresieren.Nein. Auf dem PC wird Direct3D dominieren. Noch mehr als jetzt. DX10 macht einem das Leben erheblich einfacher - keine Caps, die Softwareentwicklung gestaltet praktisch wie bei einer Konsole.
ohoho.. keine Sau. Also an der Uni ist OpenGL Standard. Wer will, kann auch DirectX für seine Progs verwenden, aber beigebracht wird einem OpenGL. Auch als Windows-Benutzer sollte man sich eben bewusst sein, dass nicht alles von MS sein muss. Und genauso, wie viele Leute aus Prinzip nie selbst ein wmv encoden würden, verwenden viele leute lieber OpenGL. Klar das Featureset war teilweise weit hinten, aber meist sind das Features, die eh fast keiner verwendet.Spieleentwickler verwenden Direct3D. Das wird in Zukunft immer mehr zum Faktum werden. Schon allein wegen dem deutlich besseren Support und den mächtigeren Tools + Debug-Runtime. Auch die Uni-Hansel werden das irgendwann mitbekommen.
Der Software-Entwickler geht den Weg des geringsten Wiederstandes, und es ist erheblich komfortabler in der DX10-Doku nachzulesen als 3 verschiedene Extensions zu unterstützen deren Dokumentation sich in einer Textdatei befindet und noch dazu keine Debug-Runtime verfügbar ist.
grandmasterw
2005-12-15, 16:42:19
Da hast du schon recht. Ich sehs aber schon mit Sorge, da das mögliche Linux oder Mac-Versionen gleich mal wesentlich schwieriger macht. Zunächst heißts, man wolle eh keine Linux-Version machen, später heißts, es is zuviel Aufwand, weil man ja DirectX verwendet hat.
Die PS3 verwendet übrigens OpenGL ES, d.h. OpenGL-Spiele könnten einfach auf die Playstation portiert werden, oder umgekehrt.
Will hier nicht über Sony oder MS streiten, find beide nicht wirklich toll, aber "keine Sau" find ich doch stark übertrieben.
Da hast du schon recht. Ich sehs aber schon mit Sorge, da das mögliche Linux oder Mac-Versionen gleich mal wesentlich schwieriger macht.Auf den Marktanteil kann man getrost scheißen aus kapitalistischer Sicht (entschuldige die Ausdrucksweise). Spiele werden nicht zum Spaß entwickelt, wie du sicher weißt.
Zunächst heißts, man wolle eh keine Linux-Version machen, später heißts, es is zuviel Aufwand, weil man ja DirectX verwendet hat.Das ist gar nicht so das Problem, die APIs unterscheiden sich kaum.
Die PS3 verwendet übrigens OpenGL ES, d.h. OpenGL-Spiele könnten einfach auf die Playstation portiert werden, oder umgekehrt.Falsch. Die Basisbefehle sind zwar gleich, aber die Shader werden gänzlich anders angesprochen. Nur weil es wie OpenGL aussieht muss es noch lang nicht schneller zu konvertieren sein. Eine PC OpenGL<->Direct3D-Konvertierung ist erheblich leichter, man muss nur die Äquivalente benützen.
micki
2005-12-15, 16:45:56
So? Welche Spiele der letzten Jahre außer Splinter Cell und Far Cry boten denn etwas was nur auf bestimmten Karten funktionierte? PS3.0 wurde nicht verwendet weil es nicht alle Karten konnten, genauso wie PS1.4 damals.[/qoute]
es gab spiele die spezielle features benutzten, informier dich bitte selber, hab hier keine lust aufzuzählen welche spiele "instanzing", "ps.schlagmichtod" usw benutzt haben. steht aber auf der rückseite so ziemlich jedes spieles.
[quote]
DX10 ist praktisch Feature-Complete, da gibts nicht viel zu erweitern.
und das glaubst du? *hahaha...*
Nein. Auf dem PC wird Direct3D dominieren. Noch mehr als jetzt.
kommt drauf an was nv in ogl reinsteckt, was nur auf deren karten läuft (vielleicht auch in der ps3).
Spieleentwickler verwenden Direct3D. Das wird in Zukunft immer mehr zum Faktum werden. Schon allein wegen dem deutlich besseren Support und den mächtigeren Tools + Debug-Runtime.
was auch ein argument für c# ist. wundert mich dass ms trotzdem keinen support dafür auf der xbox360 bisher angekündigt hat.
es gab spiele die spezielle features benutzten, informier dich bitte selber, hab hier keine lust aufzuzählen welche spiele "instanzing", "ps.schlagmichtod" usw benutzt haben. steht aber auf der rückseite so ziemlich jedes spieles.Unfug. Das sind Ausnahmen die sich an einer Hand abzählen lassen. Max Payne, Far Cry, Splinter Cell 3. Das wars im Prinzip auch schon.
Und was es den Herstellern einbringt ist Flaming von Leuten die es nicht sehen können weil sie die falsche Hardware haben.
und das glaubst du? *hahaha...*Ja. Weil ich mich damit auskenne und die Spec gelesen habe. Es gibt keine Resourcen- und Registerlimits mehr im SM4.0, außerdem sind jetzt sogar Integer-Operationen bis aufs Bitlevel möglich.
Es ist der Punkt erreicht an dem beliebige Operationen ausgeführt werden können. Es ist praktisch general-purpose. Ihr müsst euch langsam leider an diesen Gedanken gewöhnen. Wir sind bei Grafikkarten dann im Prinzip auf CPU-Level - alles ist möglich.
was auch ein argument für c# ist. wundert mich dass ms trotzdem keinen support dafür auf der xbox360 bisher angekündigt hat.Sorry, aber der Zusammenhang ist mir gänzlich unklar.
micki
2005-12-15, 16:51:25
Falsch. Die Basisbefehle sind zwar gleich, aber die Shader werden gänzlich anders angesprochen. Nur weil es wie OpenGL aussieht muss es noch lang nicht schneller zu konvertieren sein. Eine PC OpenGL<->Direct3D-Konvertierung ist erheblich leichter, man muss nur die Äquivalente benützen.
Falsch. Sony hat nicht nur die hardware von nv gekauft, sondern auch die passenden toolchains damit die entwicklung schnell möglich ist. nv entwickelt bestimmt nicht einfach nochmal die tools die sie für pc bieten, sondern werden genau die gleichen für die ps3 portieren und soweit es geht werden dann die oGL extensions and die der ps3 angeglichen sein.
Das ist nicht falsch. Eine Konsole ermöglicht immer direktere Programmierung als ein PC. Deshalb ist es auch OpenGL ES. Embeded. Es hat eben sehr spezielle Befehlserweiterungen die sich nicht direkt portieren lassen.
Auf dem PC muss man nur zwischen HLSL und GLSL umwandeln, das kann man auch automatisieren oder aus einem gemeinsamen Format wie Cg erzeugen.
micki
2005-12-15, 16:54:53
Unfug. Das sind Ausnahmen die sich an einer Hand abzählen lassen. Max Payne, Far Cry, Splinter Cell 3. Das wars im Prinzip auch schon.
Und was es den Herstellern einbringt ist Flaming von Leuten die es nicht sehen können weil sie die falsche Hardware haben.
genau das wird es in zukunft weiter geben. ein spiel verkauft sich nunmal besser, wenn es vom marketing als hightech angeprisen wird, und womit geht das besser als mit dem ausschluss von älterer hardware. die wird natürlich supported, aber ohne diese tollen features.
Ja. Weil ich mich damit auskenne und die Spec gelesen habe. Es gibt keine Resourcen- und Registerlimits mehr im SM4.0, außerdem sind jetzt sogar Integer-Operationen bis aufs Bitlevel möglich.
hui, wie suess, das hat mich aber nun wirklich ueberzeugt.
Es ist der Punkt erreicht an dem beliebige Operationen ausgeführt werden können. Es ist praktisch general-purpose. Ihr müsst euch langsam leider an diesen Gedanken gewöhnen. Wir sind bei Grafikkarten dann im Prinzip auf CPU-Level - alles ist möglich.
schade, dass deine fantasy so ein kleines techpaper limit hat.
Sorry, aber hier steig ich aus. Das habe ich definitiv nicht nötig. Streit mit nem Baum. Da kannst du immer recht haben.
grandmasterw
2005-12-15, 16:58:00
Auf den Marktanteil kann man getrost scheißen aus kapitalistischer Sicht (entschuldige die Ausdrucksweise). Spiele werden nicht zum Spaß entwickelt, wie du sicher weißt.
Mal sehn, wie lang das so bleibt. Kenn schon genug Leute, die Windows nur mehr ausschließlich zum Spielen auf der Platte haben. Wenn MS mal die Anti-Raubkopierfunktionen halbwegs (für technisch nicht versierte schwer zu umgehen) sicher machen, dann möcht ich sehn, wieviele Leute noch nen Hunderter dafür ausgeben. Windows stürzt zwar so gut wie gar nicht mehr ab, dafür werden immer mehr andere Nervigkeiten eingebaut.
Falsch. Die Basisbefehle sind zwar gleich, aber die Shader werden gänzlich anders angesprochen. Nur weil es wie OpenGL aussieht muss es noch lang nicht schneller zu konvertieren sein. Eine PC OpenGL<->Direct3D-Konvertierung ist erheblich leichter, man muss nur die Äquivalente benützen.
Hab dazu keine näheren Infos, kann mir aber schwer vorstellen, dass ne DX->OGL Konvertierung leichter ist, als ne OGLES->OGL. Ich weiß schon, was jetzt kommt "Coda weiß es, Coda sagts dir, glaubs, du Loser!" :biggrin:
micki
2005-12-15, 16:59:48
Das ist nicht falsch. Eine Konsole ermöglicht immer direktere Programmierung als ein PC. Deshalb ist es auch OpenGL ES. Embeded. Es hat eben sehr spezielle Befehlserweiterungen die sich nicht direkt portieren lassen.
Auf dem PC muss man nur zwischen HLSL und GLSL umwandeln, das kann man auch automatisieren oder aus einem gemeinsamen Format wie Cg erzeugen.
und eben dieses framework wird nv für die ps3 bieten, und wenn du mit cgfx ein paar features mehr hast als dx10 standardmässig bietet, wird es sicherlich leute zu oGL und cg ziehen. nur weil ES vieles weggelassen wird, heißt es nicht, dass nv für den pc keine features anbieten wird, wie es sie jetzt schon gibt die von dx10 nicht supported werden. aber da kann scotty glaube ich mehr zu sagen. es ist zZ unsinnig zu behauten dx10 wird das einzig tolle sein, wenn man nicht weiß was ogl bieten wird. bisher war es immer more featurerich.
Hab dazu keine näheren Infos, kann mir aber schwer vorstellen, dass ne DX->OGL Konvertierung leichter ist, als ne OGLES->OGL.Zwischen DirectX 9.0 und OpenGL auf dem PC ist im Prinzip der Unterschied nur noch der dass die Funktionen anderst heißen und die Shaderhochsprache einen anderen Syntax hat. Man kann ohne Probleme einen Zwischenlayer schreiben der beide APIs bedient.
Bei der Playstation kommen Dinge hinzu die auf dem PC nicht verfügbar sind und viel direkter programmierbar sind. Wie gesagt, wie die Funktionen heißen ist völlig unerheblich beim Konvertierungsaufwand.
grandmasterw
2005-12-15, 17:01:32
Auf dem PC muss man nur zwischen HLSL und GLSL umwandeln, das kann man auch automatisieren oder aus einem gemeinsamen Format wie Cg erzeugen.
Klar, ich konvertier die Shader, und Tadaaa, fertig ist das OpenGL Spiel. :wink:
Wenns nur danach geht, ist die Konvertierung sicher leichter als von OGLES.
Nochmal: Man kann (und es machen viele Engines: Unreal, Serious Sam, Far Cry, Ogre) einen einfachen Abstraktionslayer schreiben der per DLL OpenGL und Direct3D bedient. Der Konvertierungsaufwand beschränkt sich hier darüber alles direkt zu übersetzen auf die jeweilige andere API. Die Features sind nicht unterschiedlich.
OpenGL ES unterscheidet sich aber von den Grafik-APIs auf dem PC, auch wenn es wie OpenGL aussieht. Das die Funktionsnamen bei den Basisdingen gleich sind ist doch egal.
micki
2005-12-15, 17:07:00
Zwischen DirectX 9.0 und OpenGL auf dem PC ist im Prinzip der Unterschied nur noch der dass die Funktionen anderst heißen und die Shaderhochsprache einen anderen Syntax hat.
du solltest dich vielleicht ein wenig besser über oGL informieren damit du die unterschiede siehst, sonst würdest du deine unsinnigen behauptungen nicht aufstellen.
Man kann ohne Probleme einen Zwischenlayer schreiben der beide APIs bedient.
im prinzip hast du recht, wenn man sich aufs kgV beschränkt, kann man immer nen zwischenlayer machen, ja und? oder einen Layer wie cgFX der dann zum teil auf Dx auch laufen kann.
Bei der Playstation kommen Dinge hinzu die auf dem PC nicht verfügbar sind und viel direkter programmierbar sind. Wie gesagt, wie die Funktionen heißen ist völlig unerheblich beim Konvertierungsaufwand.
und ich wiederholle es gerne nochmal für dich, was die API zur graphik angeht, wird es nicht viel zu konvertieren geben, weil die toolchains von der ps3 auch auf pc laufen, sony weiß nunmal, dass ms sonst einen vorteil mit DX für pc und xbox hätte.
du solltest dich vielleicht ein wenig besser über oGL informieren damit du die unterschiede siehst, sonst würdest du deine unsinnigen behauptungen nicht aufstellen.Glaub mir ich kenne OpenGL in-und-auswendig. Was unterscheidet sich deiner Meinung nach denn? :)
micki
2005-12-15, 17:10:36
Nochmal: Man kann (und es machen viele Engines: Unreal, Serious Sam, Far Cry, Ogre) einen einfachen Abstraktionslayer schreiben der per DLL OpenGL und Direct3D bedient. Der Konvertierungsaufwand beschränkt sich hier darüber alles direkt zu übersetzen auf die jeweilige andere API. Die Features sind nicht unterschiedlich.
und nochmal, nicht alle features werden von d3d supported. der layer ist natürlich möglich, aber dadurch wird d3d nicht alles was oGL bietet auch nutzen können.
OpenGL ES unterscheidet sich aber von den Grafik-APIs auf dem PC, auch wenn es wie OpenGL aussieht. Das die Funktionsnamen bei den Basisdingen gleich sind ist doch egal.
das ist lowlevel, der abstraktionslayer wird weit drüber liegen. dafür gibt es schon einiges an informationen seitens sony. ein schönes xml basierendes framework ist angedacht.
StefanV
2005-12-15, 17:11:22
Was unterscheidet sich deiner Meinung nach denn? :)
Die nicht vorhandenen (Debug) Tools und die Tatsache, das man bei D3D ev. 'ne Warnung bekommt, wenn man mal mist geproggt hat.
und nochmal, nicht alle features werden von d3d supported. der layer ist natürlich möglich, aber dadurch wird d3d nicht alles was oGL bietet auch nutzen können.Was denn bitte?
Es gibt nichts. OpenGL hat mit gescheitem Render-To-Texture-Support erst jetzt auf Direct3D 9 aufgeschlossen. SM3.0-Features werden nur von GLSL unterstützt, die Low-Level-API ARB_fragment_shader/ARB_vertex_shader unterstützt nur die SM2.0-Basis und GLSL hat oftmals mit Treiberproblemen zu kämpfen.
micki
2005-12-15, 17:15:50
Glaub mir ich kenne OpenGL in-und-auswendig. Was unterscheidet sich deiner Meinung nach denn? :)
ein simples beispiel? depth bounds?
ist es unnötig? verwendet niemand? ...?
Schon ziemlich. Das ist nichtmal in DX10 eingeflossen. In Doom 3 ist es standardmäßig deaktiviert, weil es eh nichts bringt.
Weitere Beispiele?
Schon ziemlich. Das ist nichtmal in DX10 eingeflossen. In Doom 3 ist es standardmäßig deaktiviert, weil es eh nichts bringt.
Weitere Beispiele?
In Doom 3 bringt es nichts,weil die Schatten sowieso zu gross sind.In einem Spiel mit outdoor Levels ( D3 engine) wurde das ziemlich viel bringen.(mit 32 Spielern ;) )
In DX10 erübrigt sich das sowieso, weil man in der Geometry-Stage die Polygone auch ohne Depth-Bounds verwerfen kann fällt mir grad ein :)
Tja,schade dass die Inovationen an der falschen Stelle kommen.Mit (richtig schnellem) mram Speicher und on board MC koennte man einen ziemlich grossen L2 Cache ;) haben.Nich nur die Performance,sondern auch die IHVs (auch du Coda) wurden davon profitieren.
p.s. ich weiss,das hat nichts mit Software zu tun,und ist voellig OT,aber DAS verstehe ich unter "Inovation".
Mach nen Thread darüber auf, aber poste nicht dauernd kreuz-und-quer deinen MRAM-Mist rein.
Ja wenn er Mist erzählt, was will ich denn machen? OpenGL ES für die Playstation 3 ist keine PC-API (frag Demirug wenn dus mir nicht glaubst) und OpenGL unterstützt auch nicht mehr Features als DX 9 (eher das Gegenteil bis vor kurzem). Was soll die Aufregung also?
Ich hab ein Problem damit wenn man (absichtlich?) Unwahrheiten verbreitet, vor allem wenn es nur darum geht den heiligen Hersteller Sony in gutes Licht zu rücken. Das gleiche hat er schon im PS2-Thread abgezogen.
God himselfe has spoken.Die schroffe Antwort kam, weil er das schonmal in einem Thread gemacht hat. Bei jeder Gelegenheit muss er uns davon nicht überzeugen.
Asmodeus
2005-12-16, 11:31:15
Da in dieser Diskussion anklang, dass DX10 feature-complete ist würde mich interessieren, ob DX10 auch "zugriffs-complete" ist. Mit der CPU kann ich ja zu jeder Zeit auf den der Anwendung zugewiesenen Speicher lesend oder schreibend zugreifen und über Filemapping besteht z.B. auch die Möglichkeit, Teile der Festplatte wie Hauptspeicher zu nutzen. Besteht mit DX10 nun auch die Möglichkeit, z.B. zu jeder Zeit lesend oder schreibend direkt auf den Framebuffer zuzugreifen, ohne den Umweg über Texturen? Fände ich persönlich für einige Sachen extrem vorteilhaft, wenn sowas irgendwann möglich wäre.
Gruss, Carsten.
Demirug
2005-12-16, 13:22:58
Beim anlegen der Buffer gibt man an welche Zugriffrechte die CPU braucht.
D3D10 ist übrigens nicht "Feature complete".
Lesend macht das eh keinen Sinn, da das Urbild schon nach dem ersten Pixel das geschrieben wird zerstört ist, somit machen reads nur vom gleichen Pixel überhaupt sinn. Wenn du vom gleichen Pixel lesen möchtest must du halt vorher eine Kopie vom Framebuffer machen und diese als Textur verwenden - auch kein Weltuntergang und deutlich flexibler weil man das ganze Bild verwenden kann.
Ausgabe ist weiterhin der derzeitige Pixelwert, aber sonst wärs auch irgendwie keine Rasterizer-API mehr.
Ich les grad dass DX10-Karten FP-Z-Buffer und filterbare FP32-Texturen unterstützen müssen. Die Spec ist schon etwas heftig wie ich finde.
D3D10 ist übrigens nicht "Feature complete".Ja, Memexport fehlt wohl z.B. wirklich. Dennoch glaube ich nicht dass die Hersteller da in den nächsten Jahren großartig über die Spec hinausgehen werden.
Demirug
2005-12-16, 14:23:30
Lesend macht das eh keinen Sinn, da das Urbild schon nach dem ersten Pixel das geschrieben wird zerstört ist, somit machen reads nur vom gleichen Pixel überhaupt sinn. Wenn du vom gleichen Pixel lesen möchtest must du halt vorher eine Kopie vom Framebuffer machen und diese als Textur verwenden - auch kein Weltuntergang und deutlich flexibler weil man das ganze Bild verwenden kann.
Ausgabe ist weiterhin der derzeitige Pixelwert, aber sonst wärs auch irgendwie keine Rasterizer-API mehr.
Ich les grad dass DX10-Karten FP-Z-Buffer und filterbare FP32-Texturen unterstützen müssen. Die Spec ist schon etwas heftig wie ich finde.
Jetzt hast du aber gerade eine von den letzten Optionen erwischt. FP Textueren > 16Bit haben den Filter noch als Option.
Ja, Memexport fehlt wohl z.B. wirklich. Dennoch glaube ich nicht dass die Hersteller da in den nächsten Jahren großartig über die Spec hinausgehen werden.
MS spricht aber schon von D3D10+1.
Jetzt hast du aber gerade eine von den letzten Optionen erwischt. FP Textueren > 16Bit haben den Filter noch als Option.Wie kann man das dann eigentlich abfragen ohne Caps?
Demirug
2005-12-16, 14:41:15
Wie kann man das dann eigentlich abfragen ohne Caps?
"CheckFormatSupport"
Uhm, da ist dann aber doch wieder recht viel variabel oder übersehe ich was?
Z.B. ob Vertex/Indexbuffers unterstützt werden finde ich doch schon sehr seltsam.
Demirug
2005-12-16, 15:26:50
Uhm, da ist dann aber doch wieder recht viel variabel oder übersehe ich was?
Z.B. ob Vertex/Indexbuffers unterstützt werden finde ich doch schon sehr seltsam.
Du übersiehst die Liste mit den Kombinationen die zwingend erfüllt werden müssen. Die ist aber noch nicht öffentlich.
Ach so. Das konnte ich ja nicht wissen, ich kenn nur das was im SDK steht.
Godmode
2005-12-16, 23:51:13
Habs jetzt kurz überflogen und muss sagen der Geometryshader hats mir echt angetan, kann der jetzt echt neue Vertices machen?
The geometry shader runs application-specified shader code with vertices as input and the ability to generate vertices on output.
BlackBirdSR
2005-12-17, 08:51:02
Es wurden jetzt ein paar Sachen entfernt, die hier aber auch wirklich gar nichts zu tun haben.
Ich möchte einige Personen darum bitten, den Thread nicht für Charakter-Diskussionen zu benutzen.
Dafür gibts PN oder Notfalls einen anderen Thread.
Danke
Wer noch was findet, das hier raus muss, gleich melden.
ollix
2005-12-17, 11:08:58
OpenGL hat mit gescheitem Render-To-Texture-Support erst jetzt auf Direct3D 9 aufgeschlossen. -vv?
Was hat sich denn dort geändert und wie kann ich sicherstellen, daß ich "gescheitem Render-To-Texture-Support" habe? Ich habe immernoch einen GLSL Shader in der Schublade, der mehrfach RtT einsetzt und nie fehlerfrei funktioniert hat. Wahrscheinlich liegt es an mir, aber man kann ja nie wissen :)
PBuffers sind ziemlich beschissen zu verwenden weil man mehrere Render-Contexte braucht und die Resourcen deshalb sharen muss. Unter DX9 hat man einfach die Textur als Rendertarget gebunden und gut war.
Das ist unter OpenGL erst "gescheit" gelöst seit es GL_EXT_framebuffer_object gibt und da ist die Unterstützung auch immer noch nicht so ganz perfekt.
Demirug
2005-12-17, 19:46:40
Was denn im Detail?
Sorry hatte das hier übersehen.
Mir gefällt teilweise die Zuordnung der Renderstates zu den Stateobjekten nicht.
Beschränkt das irgendwie die Funktionalität oder ist nur das Interface blöd?
Demirug
2005-12-17, 21:11:47
Beschränkt das irgendwie die Funktionalität oder ist nur das Interface blöd?
Weder noch. Irgend eine Einteilung musste man halt vornehmen und das die nicht jemden gefällt dürfte klar sein.
Asmodeus
2005-12-19, 15:26:00
Mich würde noch interessieren, da ich mir die Dokumentation sparen möchte, welche neuen Features im einzelnen DX10 bieten wird, die dann erstmal mit OpenGL nicht möglich sein werden.
Gruss, Carsten.
Demirug
2005-12-19, 15:33:31
Mich würde noch interessieren, da ich mir die Dokumentation sparen möchte, welche neuen Features im einzelnen DX10 bieten wird, die dann erstmal mit OpenGL nicht möglich sein werden.
Gruss, Carsten.
Definiere "erstmal". Meinst du damit alles für das es derzeit noch keine Extension gibt?
Asmodeus
2005-12-19, 15:37:30
Definiere "erstmal". Meinst du damit alles für das es derzeit noch keine Extension gibt?
Ja, so war es gemeint.
Gruss, Carsten.
Demirug
2005-12-19, 16:45:23
Ich würde sagen die 3 primären Neuerungen (gegenüber OpenGL) sind:
Das freie Speichermodel.
Der Geometrie Shader
Stream Out hinter dem Geometrie Shader.
Asmodeus
2005-12-19, 16:52:26
Ich würde sagen die 3 primären Neuerungen (gegenüber OpenGL) sind:
Das freie Speichermodel.
Der Geometrie Shader
Stream Out hinter dem Geometrie Shader.
Auf welcher Abstraktionsebene wird der Geometrie Shader angesprochen? Gibt es dafür dann eine HL"Geometry"SL?
Gruss, Carsten.
Demirug
2005-12-19, 16:56:20
Auf welcher Abstraktionsebene wird der Geometrie Shader angesprochen? Gibt es dafür dann eine HL"Geometry"SL?
Gruss, Carsten.
Es gibt nur noch HLSL für alle Shader. Programmlänge ist unlimitiert.
Asmodeus
2005-12-19, 17:01:48
Es gibt nur noch HLSL für alle Shader. Programmlänge ist unlimitiert.
Hmm, mal ganz naiv gefragt, da im Treiber die Sachen sowieso "global" gehandhabt werden, egal ob es HLSL-Shader sind, oder GLSL-Shader, würde es dann nicht schon reichen, für GLSL auch einfach eine neue Revision zu veröffentlichen? Die kann ja dann wie bisher über GL_SHADING_LANGUAGE_VERSION_ARB abgefragt werden und schon könnte man die neuen Funktionalitäten des Geometry Shaders auch unter GLSL nutzen.
Gruss, Carsten.
Jain. Der Geometry Shader braucht auch noch andere neue Entry-Points um das Stream-Out zu benützen.
Was mir eher Sorgen macht sind die State-Objects in OpenGL, wobei man die ja nicht unbedingt unterstützen muss.
Asmodeus
2005-12-20, 08:28:29
Wird für die Benutzung des Geometry-Shaders unter HLSL eigentlich zusätzliche, neue Syntax eingeführt, oder sind in HLSL alle dafür notwendigen Befehle schon definiert? Und muss ein Eingangsvertex, der an den Geometry-Shader übergeben wird, auch Teil der Menge der Ausgangsvertices sein, wenn im Geometry-Shader neue Vertices erzeugt werden, oder kann der Eingangsvertex auch nur ein Dummy-Vertex oder Kontainer für irgendwelche Daten sein?
Gruss, Carsten.
ScottManDeath
2005-12-20, 10:21:16
Wird für die Benutzung des Geometry-Shaders unter HLSL eigentlich zusätzliche, neue Syntax eingeführt, oder sind in HLSL alle dafür notwendigen Befehle schon definiert? Und muss ein Eingangsvertex, der an den Geometry-Shader übergeben wird, auch Teil der Menge der Ausgangsvertices sein, wenn im Geometry-Shader neue Vertices erzeugt werden, oder kann der Eingangsvertex auch nur ein Dummy-Vertex oder Kontainer für irgendwelche Daten sein?
Gruss, Carsten.
Wenn Du mir Deine Email Addresse PM'st, kann ich dir die Doc schicken. Oder Du ziehst Dir das SDK und entpackst es =)
ScottManDeath
2005-12-20, 10:43:57
Hatte gerade Interview für Internship mit NVIDIA. Hab dann gleich mal gefragt, wie das mit OpenGL aussieht. :devil:
Sie werden wie zu erwarten nächstes Jahr Extensions machen. Vermutlich wohl EXT Extensions, es hängt vom ARB ab, ob es gleich ARB wird. Er meinte, dass es auch darauf ankommt, wie dann der kleinste gemeinsame Nenner aussieht.
Was interessant werden wird, ist das DX10 Vista benötigt, die Extensions aber auch unter 2K und XP laufen werden. Könnte man da als Entwickler nicht sagen, dass man OpenGL nimmt, um Vista und 2K/XK zu nutzen? Insbesondere, da auch die PS3 OpenGL ES nimmt?
Chris Lux
2005-12-20, 11:12:41
Ich würde sagen die 3 primären Neuerungen (gegenüber OpenGL) sind:
Das freie Speichermodel.
Der Geometrie Shader
Stream Out hinter dem Geometrie Shader.
an der stelle bin ich auch grad in den d3d10 specs. das geschrei hier am anfang des threads von wegen 'da wird opengl lange brauchen' usw find ich echt kindergartenniveau. nach dem lesen der spec find ich ist dx10 ein eher kleiner schritt. virtueller speicher war für mich sowieso der nächste schritt und der geometry shader mit stream output naja nix revolutionäres. für ogl glaub ich geht es ganz schnell. da wird wie hier angesprochen ein neues target für glsl zugefügt plus ein paar entypoints uns es ist gegessen.
zur api. es ist wie immer geschmackssache, aber mir gefällt sie immer noch nicht. auch wenn hier einer der meinung ist ein simpler transformationslayer reicht aus um zwischen ogl und d3d zu wandeln ist es schon ein größer aufwand durch das eher object orientierte modell von d3d. opengl ist für mich immer noch die (größtenteils) sauberere schnittstelle. für den virtuellen speicher wird es IMO recht schnell extensions geben, mit vbo und pbo sind da ja anfänge gemacht.
ich persönlich sehe keinen wirklich großen fortschritt, der andere apis obsolete machen wird.
OK, hab das für mich am meisten herausstechendste vergessen: sie haben die fixed function pipe rausgeschmissen. dieser schritt soll ja nun endlich bei opengl3.0 passieren (sollte ja bei 2.0 schon kommen :/)
Demirug
2005-12-20, 11:37:09
Um die APIs zu vereinen braucht man keinen Transformationslayer sondern einen übergeordnete Schnittstelle. Ist gar nicht so schwer sowas zu machen. Interesanterweise tendieren die meisten die ich kenne dabei eher zu einer OOP Lösung als zu einer flachen C API nach OpenGL Prinzip.
Chris Lux
2005-12-20, 13:00:07
Um die APIs zu vereinen braucht man keinen Transformationslayer sondern einen übergeordnete Schnittstelle. Ist gar nicht so schwer sowas zu machen. Interesanterweise tendieren die meisten die ich kenne dabei eher zu einer OOP Lösung als zu einer flachen C API nach OpenGL Prinzip.
ich meinte, dass ich die opengl api sauberer finde, nicht dass ich für einen transformationslayer nicht auch zu oop greifen würde.
ist es schon ein größer aufwand durch das eher object orientierte modell von d3d. opengl ist für mich immer noch die (größtenteils) sauberere schnittstelle.Blödsinn. Ich hab das schon gemacht. Ein einfacher dünner Layer über D3D und OpenGL ist völlig ausreichend, der Aufwand ist für beide APIs ungefähr gleich.
Sauberer ist keins von beidem (unsauber sind höchstens die Caps in D3D und die zig-tausend Extensions von OpenGL).
Von Render-To-Texture mit OpenGL PBuffers wollen wir ja gar nicht anfangen...
ScottManDeath
2005-12-20, 13:44:53
ich meinte, dass ich die opengl api sauberer finde, nicht dass ich für einen transformationslayer nicht auch zu oop greifen würde.
Mhmm, ich finde die OpenGL C-API irgendwie nicht mehrzeitgemäß. Mir geht es auf den Kranz, dass ich mir für jeden Schissdreck mir meine eigenen Wrapperklassen bauen muss, damit das ganze nicht in C&P Orgien ausartet. Da wäre mir eine OO API mit z.B. automatischer Ressourcenfreigabe ( wie z.B. D3D COM Objekte mit COM Smartpointers) ganz recht. Ob das OO Framework nun COM sein muss, sei dahingestellt...
Mir sind dann die 20 struktierten Klassen von D3D10 dann doch lieber als die >=500 Funktionen von OpenGL. Muss doch mal überlegen, ob ich nicht zu D3D migrieren sollte.
Die Wrapper brauchst du auch für Direct3D, ob du jetzt (z.B.) direct3d->CreateVertexBuffer oder glGenBuffersARB aufrufst ist doch Pumpe.
Das einzige wo es wirklich einen Unterschied gibt ist bei den Vertex-Declarations. Die muss man bei OpenGL vor jedem Drawcall neu setzen, bei Direct3D gibts dafür IDirect3DVertexDeclaration9.
ScottManDeath
2005-12-20, 13:59:38
Die Wrapper brauchst du auch für Direct3D, ob du jetzt (z.B.) direct3d->CreateVertexBuffer oder glGenBuffersARB aufrufst ist doch Pumpe.
Das einzige wo es wirklich einen Unterschied gibt ist bei den Vertex-Declarations. Die muss man bei OpenGL vor jedem Drawcall neu setzen, bei Direct3D gibts dafür IDirect3DVertexDeclaration9.
Schon klar. Aber ich finde es störend, wenn ich z.B. den Filter einer Textur ändern möchte, dass ich da erst das glBind machen muss. Ich kann mir vorstellen, dass der Treiber da u.U. doch recht viel validieren muss.
HAL-10K
2005-12-20, 14:02:33
Der nicht unerheblich geringere overhead von OpenGL im Gegensatz zu D3D verdeutlicht unter anderem dass OO auf der Ebene der Grafik API nichts zu suchen haben sollte.
Mag ja sein dass die breite Masse an Computerspielen (Actionshooter, etc.) wegen ihrer geringen Lastanforderungen der API mit dem aufgeblähtem D3D gut zurechtkommt.
Sobald aber Szenen mit richtig hoher Komplexität (also mehr als nur ein paar Tausend Objekten) dargestellt werden sollen, zieht OpenGL mitunter gewaltig davon.
Da hilft auch keine Geometrieinstanzierung, usw.
Dieser Unterschied wird in Zukunft in Spielen mehr Bedeutung haben.
ScottManDeath
2005-12-20, 14:07:41
Der nicht unerheblich geringere overhead von OpenGL im Gegensatz zu D3D verdeutlicht unter anderem dass OO auf der Ebene der Grafik API nichts zu suchen haben sollte.
Mag ja sein dass die breite Masse an Computerspielen (Actionshooter, etc.) wegen ihrer geringen Lastanforderungen der API mit dem aufgeblähtem D3D gut zurechtkommt.
Sobald aber Szenen mit richtig hoher Komplexität (also mehr als nur ein paar Tausend Objekten) dargestellt werden sollen, zieht OpenGL mitunter gewaltig davon.
Da hilft auch keine Geometrieinstanzierung, usw.
Dieser Unterschied wird in Zukunft in Spielen mehr Bedeutung haben.
Das hat mit OO nix zu tun. Grund dafür ist der, dass der OpenGL Treiber im User space liegt, während die D3D runtime dauernd in den Kernelspace switchen muss, weil der D3D Treiber im Kernelmodus arbeitet. In Vista wurde das gefixt...
HAL-10K
2005-12-20, 14:12:10
Das hat mit OO nix zu tun. Grund dafür ist der, dass der OpenGL Treiber im User space liegt, während die D3D runtime dauernd in den Kernelspace switchen muss, weil der D3D Treiber im Kernelmodus arbeitet. In Vista wurde das gefixt...Nö, das liegt sehr wohl an der objektorientierten Architektur von D3D. Mark Kilgard hatte dazu mal was ausführlich geschrieben (mal sehen ob ich das noch finde).
ScottManDeath
2005-12-20, 14:18:40
Nö, das liegt sehr wohl an der objektorientierten Architektur von D3D. Mark Kilgard hatte dazu mal was ausführlich geschrieben (mal sehen ob ich das noch finde).
:| Das würde mich interessieren, falls Du 'ne Quelle dazu hast.
Es stimmt auch nicht. Das neue Treiber-Interface von Longhorn wird auch DX9 beim Overhead auf OpenGL-Niveau runterbringen. Zur Zeit ist es noch so, dass Direct3D das ganze Gedöns in einen Command-Buffer überträgt den der Treiber dann wieder auseinandernehmen darf - das ist das Problem, OO hat damit rein gar nichts zu tun.
Die Behauptung entbehrt auch jeder Grundlage. Eine Indirektion mehr verursacht sicher nicht diesen Unterschied.
Demirug
2005-12-20, 14:37:18
Es stimmt auch nicht. Das neue Treiber-Interface von Longhorn wird auch DX9 beim Overhead auf OpenGL-Niveau runterbringen. Zur Zeit ist es noch so, dass Direct3D das ganze Gedöns in einen Command-Buffer überträgt den der Treiber dann wieder auseinandernehmen darf - das ist das Problem, OO hat damit rein gar nichts zu tun.
Die Behauptung entbehrt auch jeder Grundlage. Eine Indirektion mehr verursacht sicher nicht diesen Unterschied.
Aufgrund der Stateobjects dürfte der Overhead noch geringer sein.
Bei einen OpenGL Treiber wird nämlich inzwischen aufgrund der vielen Extensions die Statevalidierung immer komplexer.
Ja, und das mit den Stateobjekten wird schwierig in OpenGL nehm ich an - sagte ich ja bereits.
HAL-10K
2005-12-20, 16:53:57
Habe den genannten Beitrag leider nicht auf Anhieb gefunden.
Jedenfalls ging es um die Daten-/Befehlstrennung (opcode blah blah) und Typkontrolle in der D3D state machine, die einen Batzen Leistung kostet.
Und das ist ja ne ganze Menge: 200% und mehr bei ~50k batches mit normaler CPU-Last der Anwendung sind da locker drinn.
Das hat aber nichts mit dem Interface zu tun und wird - wie bereits gesagt - mit Windows Vista entsorgt.
HAL-10K
2005-12-20, 17:10:04
Natürlich ist nicht die Objektorientierung der Programmierschnittstelle gemeint sondern die der internen Architektur der state machine von Direct3D.
Kilgard erwähnte auch nicht Betriebssystemspezifische Aspekte, sondern bezog den Vergleich zur Architektur der state machine.
Leider hat man ja keine Einsicht in die Interna der D3D state machine (in OpenGL auch begrenzt), er natürlich mehr.
Naja, wir werden doch in etwa einem Jahr sehen ob die erwähnten erheblichen Leistungsunterschiede in der nächsten D3D-Version reduziert oder gar behoben sein werden.
Demirug hat das DDK für Vista schon gesehen.
So? Welche Spiele der letzten Jahre außer Splinter Cell und Far Cry boten denn etwas was nur auf bestimmten Karten funktionierte? PS3.0 wurde nicht verwendet weil es nicht alle Karten konnten, genauso wie PS1.4 damals.
- Riddick (Softshadows auf Geforce)
- Pacific Fighters (VTF-Wasser auf Geforce)
- AoE3 (FP16-HDR-Rendering auf Geforce; INT10-Rendering auf ATi)
- BF2/NfS:MW (PSM+PCF auf Geforce)
Mehr fällt mir auf die Schnelle nicht ein.
Q
- Riddick (Softshadows auf Geforce)Das ist nur PS2. Das funktioniert nicht auf ATI, weil eine nVIDIA-Extension verwendet wurde.
- Pacific Fighters (VTF-Wasser auf Geforce)Ja.
- AoE3 (FP16-HDR-Rendering auf Geforce; INT10-Rendering auf ATi)Hat nichts mit dem Shadermodell zu tun.
- BF2/NfS:MW (PSM+PCF auf Geforce)Dito. PSM ist Hardwareunabhängig, bei PCF magst du recht haben.
Mehr fällt mir auf die Schnelle nicht ein.Mehr als diese Kleinigkeiten gibt es auch nicht.
andererGast
2006-01-09, 14:32:51
Coda, du fragtest auch nicht nach dem Shadermodell, sondern welche Spiele etwas boten, was nur auf bestimmten Grakas möglich ist.
Mag ja sein, der Anteil ist trotzdem verschwindend gering und es sind bis auf SC3 wirklich nur Kleinigkeiten.
Microsoft DirectX SDK (February 2006) ist erschienen:
http://msdn.microsoft.com/directx/sdk/readmepage/default.aspx
October 2006 DirectX SDK Downloads
DirectX SDK - October 2006
New features in this release include HLSL shader debugging within PIX, a preview release of Direct3D 10 HLSL shader compilation for Direct3D 9 targets, plus updates to XACT, XInput, and UVAtlas.
http://msdn.microsoft.com/directx/sdk/
Schon experimentiert, Leute?
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.