spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »Spiele Programmierer«

Zitat

Wer sagt dass der Renderer auf allen Plattformen die selbe API verwenden muss?

Doppelte Arbeit? Wozu? Bloß damit DirectX auch zum Zug kommt?

Nein. Z.B. damit ich vernünftige Performance auf Intel Karten mit ihren grottigen OpenGL Treibern hab. Mittlerweile is das schon besser, aber vor nicht all zu langer Zeit konnte es passieren, dass man allein durch die Portierung nach Direct3D die Performance verdoppelt konnte, weil die OpenGL Treiber mancher Karten so schlecht waren (betrifft hauptsächlich so On-board Chips wie die meisten Laptops sie haben). Abgesehen davon deckt OpenGL nicht alles ab was man in einer ernsthaften Anwendung braucht. Enumeration und Context Creation laufen beispielsweise eben nur über Plattformspezifische APIs (wgl, glx etc.).
Und dann macht der Renderer sowieso nur einen kleinen Teil einer ernsthaften Anwendung aus.
Natürlich wird es nicht immer sinnvoll sein, aber es gibt eben doch gute Gründe, warum man unter Windows Direct3D verwenden will, selbst wenn man auf anderen Plattformen gezwungenermaßen OpenGL oder sonstige APIs benutzt.

Zitat von »Spiele Programmierer«

Zitat

Draw ohne Vertex Buffer

Hä?
Wo wir doch vorhin erst über den immidate mode gerredet habe?
Außerdem gibt es ja Displaylisten.

Ich rede nicht von Immediate Mode, Displaylisten oder sonstigem Kram aus dem letzten Jahrtausend, sondern von der Möglichkeit, Vertices über den Vertex Shader zu erzeugen ohne einen Buffer zu verwenden. Das kann massiv Bandbreite sparen, z.B. wenn ich Millionen von Sprites rendern will. Unter OpenGL nicht möglich (ich kenn nur einen Driver Hack auf den ich mich lieber nicht verlassen würde).

Zitat von »Spiele Programmierer«

Zitat

Random Memory Access in Shadern

Was meinst du damit?

Genau das: Lesen und Schreiben aus dem/in den Grafikspeicher vom Shader aus (auch bekannt als Gathering/Scattering). Für viele aktuellere Techniken ein essentielles Feature. Unter OpenGL nur über herstellerspezifische Extensions verfügbar (NV_shader_buffer_load, NV_shader_buffer_store etc.)

Zitat von »Spiele Programmierer«

Zitat

Schau dir mal Direct3D 11 an

Anschaun? gern!
Aber auf meinen Computer(genauer gesagt wegen der Grafikkarte) läufts nicht.

Wenn du eine Direct3D 9 fähige Grafikkarte oder besser hast, dann läuft's bei dir.

Zitat von »Spiele Programmierer«

Zitat

Wenn du Speicherlecks erzeugst, dann ist das nicht die Schuld von Direct3D. Direct3D ist, dank COM, perfekter Kandidat für RAII. Mit OpenGL gestaltet sich das, aufgrund des merkwürdigen Objektmodells, meiner Erfahrung nach teilweise schwieriger.

Vielleicht machst du da was falsch?
Ich kapsle in OpenGL normalerweiße die OpenGL Funktionen immer in einer Klasse. (-> Ja auch ich mag OO)

Ich halte zwar nicht viel von Wrappern, aber es würde mich sehr interessieren wie du da vorgehst. Meiner Erfahung nach ist es praktisch unmöglich OpenGL vernünftig in Klassen zu wrappen. Durch das merkwürdige Objektmodell (der ganze Bind Kram), ist das entweder nur sehr ineffizient möglich, oder man kann eben kein richtiges OOP betreiben.
Genau das ist eines der großen Problem von OpenGL, macht auch das Implementieren von Treibern zu einer weniger angenehmen Sache was man so hört und sorgt für unnötigen Overhead, der unter gewissen Umständen sogar ein performance-limitierender Faktor werden kann.

Zitat von »Spiele Programmierer«

Es kann auch sein das sich vielleicht auch wircklich an manchen Stellen was geändert hat.

Was war denn die letzte Version von Direct3D mit der du so zu tun hattest?

Zitat von »Spiele Programmierer«

EDIT:
Ich seh grad das ich was ausgelassen hab:

Zitat

multithreaded Rendering

Hab micht ehrlichgesagt noch nie damit beschäftigt.
Ich programmiere auch in letzter Zeit eher Anwendungen, da kommt es auf sowas nicht so an.
Gennerell kann ich es mir aber schon vorstellen. Man müsste die Funktionen entweder Kapseln und den Zugriff verwalten oder mehrere Renderingcontexte nutzen.

Mehrere Kontexte sind genau der Alptraum von dem ich vorhin gesprochen hab. Aber damit muss man sich ja auch schon rumschlagen wenn man z.B. nur auf mehreren Bildschirmen/Grafikarten rendern will. (Multidisplay ist wieder so eine Sache die in Direct3D ganz klar und simpel gelöst ist, in OpenGL aber zur Qual wird, bzw. eh auch wieder nicht plattformunabhängig machbar ist)
Multithreaded Rendering im Stile von Direct3D (paralleles Füllen von Command Buffern) ist mit OpenGL momentan afaik absolut unmöglich.

Zitat von »Spiele Programmierer«

Gibt es in DirectX eine Möglichkeit Daten über die Speicherauslasung zu ermitteln?

Nein. Das ist nicht wirklich sinnvoll möglich, da der Grafikspeicher unter Windows virtualisiert ist.

Zitat von »Spiele Programmierer«

Zitat

sondern von der Möglichkeit, Vertices über den Vertex Shader zu erzeugen ohne einen Buffer zu verwenden

Sowas Änliches ist mit OpenGL und Instanzing(Extension ) oder Geometry Shader möglich.

Nein, das ist was völlig anderes.

Zitat von »Spiele Programmierer«

Zitat

Genau das: Lesen und Schreiben aus dem/in den Grafikspeicher vom Shader aus

Schreiben geht auch mit TransformFeedback. (Ebenfalls Extension )

Nein, das ist was völlig anderes.

Zitat von »Spiele Programmierer«

Zitat

Wenn du eine Direct3D 9 fähige Grafikkarte oder besser hast, dann läuft's bei dir.

Ich weiß nur das DirectX 11 Samples aus dem SDK bei mir grundsätzlich abgestürtzt sind.

Natürlich laufen keine Dinge die Direct3D 11 Hardware benötigen auf dieser Karte. Nichts desto trotz kannst du in Direct3D 11 programmieren, du musst dich eben auf den entsprechenden Feature Level beschränken.

Zitat von »Spiele Programmierer«

Zitat

Ich halte zwar nicht viel von Wrappern

Auch dein toller Renderer ist im Prinzip ein Wrapper.

Nein.

Zitat von »Spiele Programmierer«

Zitat

Was war denn die letzte Version von Direct3D mit der du so zu tun hattest?

DirectX 9(aus C++) und *räusper* Managed DirectX.

Gegenüber Direct3D 9 hat sich inzwischen sehr viel verändert.

Zitat von »Spiele Programmierer«

Zitat

Ich halte zwar nicht viel von Wrappern, aber es würde mich sehr interessieren wie du da vorgehst.

Ich weiß nicht wo da die große Schwierigkeit ist.
Wenn du willst kann ich dir auch Code zeigen.

Erklär mir einfach nur wie du z.B. eine OpenGL Textur vernünftig in eine Klasse wrappen willst. Du hast also diese Klasse mit der Texture id als Member. Was für Methoden hat diese Klasse nun und wie implementierst du sie?
Sämtliche OpenGL Calls die auf Texturen arbeiten, referenzieren nicht direkt ein Texturobjekt, sondern beziehen sich auf ein globales Texture Target. Bevor du irgendwas mit einer Texture machen kannst, musst du sie zuerst in ein entsprechendes Target binden. Wenn du deiner Klasse also irgendwelche Methoden im Sinne der OOP verpassen willst, dann musst du am Anfang jeder Methode ein glBindTexture() stehen haben, was wahnsinnig ineffizient ist.
Die exakt selben Probleme hast du mit fast allen anderen OpenGL Objekten.
Wenn du eine gute Lösung dafür hast, dann würd ich sie wirklich sehr gern sehen, denn ich hab noch keine gefunden mit der ich zufrieden gewesen wäre...

Zitat von »Spiele Programmierer«

EDIT:
Nochmal zur Performace:
Normalerweiße liest man, das OpenGL ein klein wenig schneller ist.

Man sollte eben nicht alles glauben was man liest

Zitat von »Spiele Programmierer«

Zitat

Nein, das ist was völlig anderes.

Wo liegen die Unterschiede?

Ist natürlich nicht genau das selbe, kann aber das andere Ersetzten.

Nein kann es nicht. Genaueres siehe z.B. der verlinkte Artikel. Ansonsten überleg dir einfach mal kurz, wie du z.B. sowas umsetzen würdest

Zitat von »Spiele Programmierer«

Zitat

Auch dein toller Renderer ist im Prinzip ein Wrapper.
Nein.

Ich würde schon sagen das dein Renderer in diese Kategorien fällt:

Zitat

Allow code to work together which otherwise cannot (e.g. Incompatible data formats).
Enable cross language and/or runtime interoperability.

Ein Wrapper (auch bekannt als Adapter) ist ein Layer, dessen primärer Zweck nicht die Abstraktion, sondern das Anpassen einer Schnittstelle an eine andere Schnittstelle ist.
Wenn ich einen Renderer für eine Anwendung schreibe, dann ist das bei mir eine anwendungsspezifische Abstraktion und kein Adapter.

Zitat von »Spiele Programmierer«

Zitat

Gegenüber Direct3D 9 hat sich inzwischen sehr viel verändert.

Schon möglich.
Für mich ist DirectX 10 oder höher aber wegen der XP inkompatibilität nicht spruchreif.

Ja, wenn du XP unterstützen musst, dann bleibt dir nur Direct3D 9.

Zitat von »Spiele Programmierer«

Zitat

Was für Methoden hat diese Klasse nun und wie implementierst du sie?
Sämtliche OpenGL calls die auf Texturen arbeiten, referenzieren nicht direkt ein Texturobjekt, sondern beziehen sich auf ein globales Texture Target. Bevor du irgendwas mit einer Texture machen kannst, musst du sie also zuerst in ein entsprechendes Target binden. Wenn du deiner Klasse also irgendwelche Methoden im Sinne der OOP verpassen willst, dann musst du am Anfang jeder Methode ein glBindTexture() stehen haben, was wahnsinnig ineffizient ist.

Schon klar.
Aber wo ist da das Problem?
Entweder meine Texture Klassen hat ein "Begin" und ein "End" oder ich merke mir die momentan aktive Texture global und setzte diese fals nötig automatisch.

Das ist aber imo weder gut noch sinnvoll. Denn damit kann ich nun sowas machen:


Imo ein sehr deutliches Zeichen, dass das da keine Methoden sein sollten.

Zitat von »Spiele Programmierer«

Zitat

Man sollte eben nicht alles glauben was man liest.

DU sagst es.

Ich empfehle sehr, bei Artikeln die sowas behaupten das Datum zu beachten. Das übliche Argument warum OpenGL angeblich schneller sein soll, ist dass OpenGL direkt durch den Treiber implementiert wird und dabei viel im User Mode machen kann, während Direct3D eine Runtime dazwischen hat und viel öfter einen Kernel Call absetzten muss.
Vor in etwa 15 Jahren war das sogar korrekt. Aber schon damals hat das in der Praxis keine Rolle gespielt.
Und heute besitzt auch die Direct3D Architektur einen eigenen User Mode und einen Kernel Mode Layer. Und abgesehen davon ist das State Management in Direct3D extrem effizient. Die ganze API wurde mit Direct3D 10 von Grund auf neu designed, wobei minimaler Overhead eines der Hauptziele war. Ich würde sogar davon ausgehen, dass Direct3D mittlerweile einen Perfomancevorteil hat was das betrifft.
Brauchbare Treiber vorausgesetzt, ist mir in der Praxis aber bisher noch nie ein irgendwie nennenswerter Unterschied aufgefallen, wobei ich allerdings auch noch nie direkt verglichen habe.

Abgespalten von hier.

Zitat von »Spiele Programmierer«

Zitat aus Wikipedia:

Zitat
Draw Call-Kosten sind niedriger als in Direct3D, was zu einer besseren Performance führt.

Nicht alles was Wikipedia verbreitet muss auch stimmen. Die Quelle von Wikipedia ist immerhin 6 Jahre alt.

Immerhin ist selbst Carmack der Meinung das Direct3D is now better than OpenGL