Du bist nicht angemeldet.
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!
10.07.2012, 22:05
Zitat
Natürlich kann man das so "lösen". Der Punkt ist, dass man mit jeder derartigen Lösung zwangsweise unnötigen Overhead in Kauf nimmt...
Es geht eher darum, dass man dadurch (ungewollt) einen globalen Zustand ändert.
Direct3D ist genau wie OpenGL als Satemachine aufgebaut. Zugegeben es gibt Methoden mit denen man Resourcen wie z.B. Texturen direkt manipulieren kann. Das eigentliche Rendern funktioniert aber genau wie bei OpenGL. An Stelle von Bind benutzt man halt SetTexture oder SetStreamSource. Hier werden ebenfalls globale States gesetzt.
Der Punkt ist, dass OpenGL eben nicht mit OOP im herkömmlichen Sinn kompatibel ist. Das ist aber gar nicht mein Hauptkritikpunkt, das imo wirklich große Problem, ist der globale Zustand, der hinter allem steckt...
Exakt und das ist nicht nur eine unerschöpfliche Quelle für unglaublich lustige Bugs, sondern disqualifiziert die API von vornherein für Multithreading.
EDIT: Ok, natürlich ist Multithreading mit OpenGL, zumindest in gewissem Rahmen (asynchrones Ressourcenmanagement), möglich, allerdings imo sehr anstregend. Für multithreaded Rendering gibt's immer noch keine Lösung...
Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »stef« (11.07.2012, 08:00)
10.07.2012, 22:22
Was soll ungewollt geändert werden ? Wenn du eine Resource benötigst machst du ein Bind, wenn du sie benutzt hast machst du den Bind rückgängig. Wenn du das konsequent durchziehst hat du keine Probleme.
Direct3D ist genau wie OpenGL als Satemachine aufgebaut. Zugegeben es gibt Methoden mit denen man Resourcen wie z.B. Texturen direkt manipulieren kann. Das eigentliche Rendern funktioniert aber genau wie bei OpenGL. An Stelle von Bind benutzt man halt SetTexture oder SetStreamSource. Hier werden ebenfalls globale States gesetzt.
DirectX11 ermöglicht durch asynchrones aufrufen von Renderfunktionen (Command Lists) ein einfaches nutzen der GPU Rechenzeiten auf Applikationsseite. Da ist die API in der Tat OpenGL überlegen. Aber machen wir uns nichts vor, ein wirkliches Paralleles Rendern ist auch damit noch nicht möglich. Die GPU (auch kaskadierte) ist und bleibt eine Exklusivresource die alle Renderjobs seriell ausführt.
Bezüglich OO allgemein: DirectX hat gegenüber OpenGL den Vorteil das es nur auf einer Plattform eingesetzt wird. OpenGL ist eine Plattformübergreifende API. Deshalb ist sie in C umgesetzt weil das immer noch am einfachsten in allen Umgebungen (z.B. JAVA) zu integrieren ist. Das sollte man bei der Diskusion beachten.
Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von »dot« (10.07.2012, 22:36)
10.07.2012, 22:36
Der State ist bei Direct3D eben genau nicht global, sondern in einem Objekt gekapselt. Ich kann im selben Thread mit beliebig vielen Devices und Contexts tun, was auch immer mir in den Sinn kommt, ohne irgendwo ständig über meine eigenen Füße zu stolpern...
Direct3D erlaubt mir, den Overhead auf CPU Seite zu parallelisieren. Dass der Command Stream zur GPU natürlich seriell sein muss, ist logisch, denn ein völlig paralleles Rendern würde kaum Sinn machen, da normalerweise die Reihenfolge eben wichtig ist.
Man kann auch in C objektorientiert programmieren. OpenGL macht es z.B. bei den Shadern sogar einigermaßen richtig.
10.07.2012, 22:42
OpenGL macht es z.B. bei den Shadern sogar einigermaßen richtig
Deshalb ist sie[OpenGL] in C umgesetzt.
10.07.2012, 22:43
Der State ist bei Direct3D eben genau nicht global, sondern in einem Objekt gekapselt. Ich kann im selben Thread mit beliebig vielen Devices und Contexts tun, was auch immer mir in den Sinn kommt, ohne irgendwo ständig über meine eigenen Füße zu stolpern...
Möchte ich bezweifeln. Wenn du einmal SetTexture aufgerufen hast gillt die Texture (globaler Sate) für alle Draw, Render usw. Funktionen bis eine ander Textur gesetzt ist. In der Zeit wo die Texture gesetzt ist kannst du damit nicht alles machen was du willst ohne die Ausgabe zu beeinflußen.
Man kann auch in C objektorientiert programmieren. OpenGL macht es z.B. bei den Shadern sogar einigermaßen richtig.
Shaderobjekte werden unter OpenGL mit Use an Stelle von Bind angesprochen. Ansonnsten ist die Mechanik aber die gleiche (Handle auf Programm usw.). Was genau ist da denn anderst ?
10.07.2012, 22:46
Dass die entsprechenden Funktionen nicht von einem globalen Bind Target abhängen
10.07.2012, 22:47
Ich kann eine OpenGL-API genauso in C++ oder Pascal programmieren.
10.07.2012, 22:50
Dass die entsprechenden Funktionen nicht von einem globalen Bind Target abhängen
Äh, eigentlich schon.
Versuch zb. mal den Uniformwert einer Variable eines ungebundenen Shaders zu ändern.
10.07.2012, 22:51
Der Punkt ist das du eine C++ Schnittstelle mit This-Calls, Templates und Exceptions schwer, wenn nicht gar nicht auf andere Umgebungen (z.B. Java auf Android) heben kannst.
26.04.2024, 15:51
Zum Seitenanfang
