Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!
Werbeanzeige
Zitat
Wer sagt dass der Renderer auf allen Plattformen die selbe API verwenden muss?
Zitat
Die Möglichkeit Shader offline zu kompilieren
Zitat
Draw ohne Vertex Buffer
Zitat
Random Memory Access in Shadern
Zitat
Schau dir mal Direct3D 11 an
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.
Zitat
multithreaded Rendering
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Spiele Programmierer« (21.02.2012, 00:05)
Zitat
Wer sagt dass der Renderer auf allen Plattformen die selbe API verwenden muss?
Doppelte Arbeit? Wozu? Bloß damit DirectX auch zum Zug kommt?
Zitat
Draw ohne Vertex Buffer
Hä?
Wo wir doch vorhin erst über den immidate mode gerredet habe?
Außerdem gibt es ja Displaylisten.
Zitat
Random Memory Access in Shadern
Was meinst du damit?
Zitat
Schau dir mal Direct3D 11 an
Anschaun? gern!
Aber auf meinen Computer(genauer gesagt wegen der Grafikkarte) läufts nicht.
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)
Es kann auch sein das sich vielleicht auch wircklich an manchen Stellen was geändert hat.
Dieser Beitrag wurde bereits 9 mal editiert, zuletzt von »dot« (21.02.2012, 00:30)
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.
Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »dot« (21.02.2012, 00:47)
Zitat
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.).
Zitat
sondern von der Möglichkeit, Vertices über den Vertex Shader zu erzeugen ohne einen Buffer zu verwenden
Zitat
Genau das: Lesen und Schreiben aus dem/in den Grafikspeicher vom Shader aus
Zitat
Wenn du eine Direct3D 9 fähige Grafikkarte oder besser hast, dann läuft's bei dir.
Zitat
Ich halte zwar nicht viel von Wrappern
Zitat
Was war denn die letzte Version von Direct3D mit der du so zu tun hattest?
Zitat
Ich halte zwar nicht viel von Wrappern, aber es würde mich sehr interessieren wie du da vorgehst.
Gibt es in DirectX eine Möglichkeit Daten über die Speicherauslasung zu ermitteln?
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.
Zitat
Genau das: Lesen und Schreiben aus dem/in den Grafikspeicher vom Shader aus
Schreiben geht auch mit TransformFeedback. (Ebenfalls Extension )
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.
Zitat
Ich halte zwar nicht viel von Wrappern
Auch dein toller Renderer ist im Prinzip ein Wrapper.
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.
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.
EDIT:
Nochmal zur Performace:
Normalerweiße liest man, das OpenGL ein klein wenig schneller ist.
Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von »dot« (21.02.2012, 01:12)
Zitat
Nein, das ist was völlig anderes.
Zitat
Auch dein toller Renderer ist im Prinzip ein Wrapper.
Nein.
Zitat
Allow code to work together which otherwise cannot (e.g. Incompatible data formats).
Enable cross language and/or runtime interoperability.
Zitat
Gegenüber Direct3D 9 hat sich inzwischen sehr viel verändert.
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.
Zitat
Man sollte eben nicht alles glauben was man liest.
Zitat
Nein, das ist was völlig anderes.
Wo liegen die Unterschiede?
Ist natürlich nicht genau das selbe, kann aber das andere Ersetzten.
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.
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.
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.
C-/C++-Quelltext |
|
1 2 |
texture1.bind();
texture2.doSmth(); // tut was mit texture 1
|
Zitat
Man sollte eben nicht alles glauben was man liest.
DU sagst es.
Dieser Beitrag wurde bereits 7 mal editiert, zuletzt von »dot« (21.02.2012, 01:57)
Zitat
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
Wenn ich einen Renderer für eine Anwendung schreibe, dann ist das bei mir eine anwendungsspezifische Abstraktion und kein Adapter.
Zitat
Das ist aber imo weder gut noch sinnvoll. Denn damit kann ich nun sowas machen:
Zitat
Ich empfehle sehr, bei Artikeln die sowas behaupten das Datum zu beachten. Das übliche Argument warum OpenGL angeblich schneller sein soll
Zitat
Draw Call-Kosten sind niedriger als in Direct3D, was zu einer besseren Performance führt.
Zitat aus Wikipedia:
Zitat
Draw Call-Kosten sind niedriger als in Direct3D, was zu einer besseren Performance führt.
Werbeanzeige