[OpenGL] "Modernes" Programmiermodell wie DirectX?

[Schrompf]

Moin Leute,

ich fange gerade die Portierung meines Spiels auf Mac/Linux an. Dazu muss ich den Renderer auf OpenGL portieren. Nach meinem Wissen ist nun OpenGL aber eine ganz furchtbar state-behaftete Sauerei, bei der ich jeden Buffer/Textur/Shader binden muss, bevor ich ihn verändern kann.

Gibt es ein modernes Programmiermodell für OpenGL?

Falls das nur über Extensions geht: hat jemand Erfahrungen, wie verlässlich die Extensions bei den drei großen Vendors NVidia/ATI/Intel laufen?

Falls es mit einem Core Profile geht: wie verbreitet und verlässlich ist das Profile auf Windows/Mac/Linux? Hat da jemand Erfahrungswerte?

[dot]

Es hängt sehr stark davon ab, was für ein Spektrum and Hardware du supporten musst. OpenGL ist imo ab 3.3 core auf einem Stand, wo man sich zumindest nicht mehr ständig die Augen auskratzen will. Leider geht OS X erst seit der letzten Version über OpenGL 3.2 raus und unter Linux stellt der Mesa Kram mit Intel GPUs ebenfalls eine harte Barriere bei 3.2 dar. Und da denkt man, wir hätten 2014 oder sowas...

Extensions würde ich um jeden Preis vermeiden, that way lies madness...

[Spiele Programmierer]

Eine sehr nette Extension "EXT_direct_state_access", damit kann man (fast) jeden State auch direkt zugreifen, falls das dein Wunsch ist. Leider ist das kein verlässliches Standbein, wie du übrigens hier auf der Hardwaredatenbank für die gröbste Orientierung nachschlagen kannst. (66% Verfügbarkeit)
Also modern sieht man OpenGL 3.3 mit Core Profile an. Leider kann man sich selbst auf dessen Verfügbarkeit nicht wirklich verlassen. (Siehe u.a. Hardwaredatenbank) Mesa ist übrigens prinzipiell schon seit Version 10 auch bei 3.3 angekommen.

Was manche Leute so krankhaft gegen Extensions haben, verstehe ich ehrlich gesagt nicht wirklich. Für manche Features sind Extensions notwendig(Anisotrope Texturfilterung zum Beispiel) und werden auch sehr breit unterstützt. Extensions können die Features auch deutlich nach oben treiben. Wo es auf Dx heißt "Ätsch, neues OS notwendig" kann man mit Extensions noch einiges herausholen. Neuere Features werden außerdem immer als funktionsäquivalente ARB-Erweiterungen herausgebracht. Damit kann man teilweise neuere Funktionen uneingeschränkt aufwärts kompatibel auch auf älterer Hardware nutzen, selbst wenn es nicht für eine komplette Unterstützung aller Features für die neue Ogl Version gereicht hat. Wenn es entsprechende verfügbare Core-Features gibt, sind diese natürlich vorzuziehen, aber manchmal können Extensions echt nützlich sein. Man muss nur deren Verwendung richtig kapseln.

[antisteo]

Wenn du ganz konservativ sein willst, nimm einfach den GLES2.0-Header und linke ihn gegen die OpenGL-Bibliothek. GLES2.0 ist exakt der DX9-Umfang und du bekommst damit alles hin, was du brauchst. Zusätzlicher Vorteil: Splatter auf dem Raspberry Pi.

Das saubere Programmiermodell denkst du dir im Prinzip selbst aus:
- Du überlegst dir, welchen State du jedes mal ändern willst. Diesen musst du dann jedes mal ändern, da du jeden vorhergehenden Wert für den State annimmst. Beispiel sind die Texturen und der verwendete Vertexbuffer.
- Du überlegst dir, welchen State du immer nach gewissen Phasen ändern willst. Beispiel wären gewisse Leuchtquellen, die nur beim Partikelsystem abgestellt werden (als Uniforms natürlich; nicht die ffp).
- Du überlegst dir, welchen State du immer wieder auf ein Default zurückändern wirst. Dann entfällt dir der Overhead, das ständig zu ändern, wenn es gleich bleibt. Beispiel wäre der verwendete Shader oder die initialisierten Vertexattribut-Slots.

Du wählst deine eigene Konvention nach Performance-Gesichtspunkten (Mehr Texturwechsel? Oder doch lieber Vertexbuffer ständig durchwechseln?) und dokumentierst genau, welchen Teil des States du wann ändern willst (oder auf welchen Default-Wert er zurückgesetzt werden muss).

[Spiele Programmierer]

OpenGL ES ist aber keine Teilmenge von OpenGL, auch wenn vieles Übereinstimmt.
Da wäre also Vorsicht angebracht.

[antisteo]

OpenGL ES ist aber keine Teilmenge von OpenGL, auch wenn vieles Übereinstimmt.

GLES2.0 ist eine Teilmenge von GL 4.1. Bis auf einige Zusatzstates beim Depth Buffer und bei den Texturen ist GLES2.0 aber exakt GL2.0-Niveau.

[Schrompf]

Und wie verbreitet ist OpenGL ES2.0? Kann ich mich darauf verlassen, dass ich damit auf allen Systemen der letzten fünf Jahre an die GPU komme? Dann wäre das ja ne feine Sache.

[antisteo]

Und wie verbreitet ist OpenGL ES2.0? Kann ich mich darauf verlassen, dass ich damit auf allen Systemen der letzten fünf Jahre an die GPU komme? Dann wäre das ja ne feine Sache.

Die letzten 10 Jahre mindestens. Außerdem sämtliche Embedded-Geräte. Der WebGL-Standard ist ebenfalls verkapptes GLES2.0. Es gibt sogar eine Bibliothek (im Firefox), die GLES2.0 nach DirectX 9 wrappt.

[Schrompf]

OpenGL ES 2.0 wurde laut Wikipedia 2007 definiert. Soviel zum Thema "mindestens 10 Jahre" :-) Allerdings bin ich da immernoch unsicher: die deutsche Wikipedia schreibt nur über Embedded Systems, die englische Wikipedia nennt auch "Windows7" als Plattform, aber unter den unterstützten GPUs fehlt ATI/AMD völlig. Linux wird allerorten unterstützt, aber ist das treiberseitig dann auch zuverlässig oder ist das wieder so ne Ausnahmen-Workaround-Wüste wie OpenGL?

[kristof]

Mir wäre kein Weg bekannt wie man unter Mac OS X gegen OpenGL ES programmieren könnte. Es gibt zwar die Tools um damit für iOS zu entwickeln, aber für den Desktop selbst glaube ich nicht. Ob es funktioniert einfach einen OpenGL ES Header zu nehmen habe ich allerdings nie probiert.
Ich programmiere auf dem Mac eigentlich immer gegen das OpenGL 3.2 Core Profile. Auf Systemen ab Mac OS 10.7.5 wird einem von Apple soweit ich weiss garantiert, dass das vorhanden ist. In Shadern kann man natürlich immer noch über Hardware spezifische Probleme stolpern.
Diesen Link (https://developer.apple.com/graphicsima ... _Core.html) habe ich gerade noch entdeckt. Das mag dir vielleicht auch noch weiter helfen.
Und nimm auf jeden Fall SDL oder etwas ähnliches her. Fang auf keinen Fall an direkt gegen die Cocoa Frameworks zu programmieren. Den Umgang mit Objective-C kann man niemandem wünschen...

[Spiele Programmierer]

Als Contextlib habe ich sehr gute Erfahrungen mit dem relativ kleinen GLFW(3) gemacht. Das besitzt übrigens bei der Contexterstellung auch eine Einstellung um einen OpenGLES-Context zu erstellen. Kommt auch auf MacOS und Linux zurecht. Als OpenGL Loader bieten sich zum Beispiel GLEW(sehr umfangreich) oder GLLoadGen(Lua script, dass dir genau die Teile generiert, die du brauchst) an.

Nochmal wegen OpenGL ES...
Halbwegsaktuell...
http://www.g-truc.net/post-0457.html

[Schrompf]

Ich baue mir gerade SDL2 als diesen Layer. Evtl. sollte ich mir doch mal andere Libs angucken. Die SDL ist groß und miserabel segmentiert - ich kriege z.B. deren Audio-System partout nicht rausoperiert, obwohl ich es definitiv nicht brauche.

Das SDL-Projekt triggert außerdem auf MSVC12 einen Compiler-Bug, sobald man den Compiler auf SSE2 stellt.

Code: Alles auswählen

2>SDL_gesture.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "__ftoui3" in Funktion "_SDL_HashDollar".
2>SDL_string.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "__dtoui3" in Funktion "_SDL_PrintFloat".

Schon bekannt in den SDL-Foren, aber anscheinend hat es noch niemand Microsoft mitgeteilt.

[Spiele Programmierer]

Na, dann verwende doch GLFW. :?:
Das ist nur(!) Window-Erstellung und wirklich einfach und klein.
SSE2 habe ich auch immer angestellt und geht.

[Sternmull]

Es ist zwar schon ein paar Jährchen her das ich ernsthaft was mit OpenGL gemacht habe, aber gegen Extensions ist meiner Ansicht nach absolut nichts einzuwenden. Dadurch kann man eine angestaubte OpenGL als Basisvoraussetzung annehmen (die kann ruhig 10 Jahre oder mehr alt sein) und holt sich die moderne Funktionalität selektiv per Extensions (oder eben nicht wenn nicht verfügbar, sofern man eine Deaktivierung von Features bzw. ein Fallback hinnehmen kann). Die Extensions sind ja nichts weiter als Funktionszeiger die man sich vom Treiber holt und ein paar Konstanten die man vorher kennen muss (natürlich gehört auch noch ne Doku dazu, aber die ist ja nicht im Code). Um die Extensions bequem einzubinden sind GLEW und GLEE geeigent (die sind sogar auf Wikipedia erwähnt :) ). Die generieren ihren Code aus den Dokus und dürften eigentlich immer das neuste drin haben.

Die Objektstrukturen/States von OpenGL kosten in der Tat etwas Einarbeitungszeit. Aber wenn man da durchsteigt und bei dem modernen Teil der API bleibt, dann ist das im Prinzip auch objektorientiert. Evtl. lohnt sich auch ein Blick auf OglPlus was die C-API von OpenGL mit einer schlanken C++ Schnittstelle kapselt. Hab ich selbst noch nicht ernsthaft verwendet, ist aber auf jeden Fall einen Blick wert um bei der Struktur durchzusteigen (wie sich die Sache in Klassen kapseln lässt). Unerlässlich ist auch das OpenGL Wiki dort wird z.B. die Objekt-Struktur erklärt. Wenn man das alles verinnerlicht hat sollte man eigentlich gute Karten haben ein D3D-Programm sinnvoll zu portieren.

Ich würde auch dazu Raten sich (zumidnest weitgehend) auf die Schnittmenge von OpenGL und OpenGL ES zu beschränken. Einerseits erzwingt das die Nutzung der modernen API und andererseits führt es dazu das einer Mobile-Version zumidest von der Grafik-Implementierung her nichts mehr im Wege steht. In Spezialfällen wie Shader-Features und Textur-Formaten kann spezialisierter Code für die Desktop/Mobile-API aber sinnvoll sein. In C++ ist das aber alles ganz gut handhabbar (ein paar #ifdefs werdens schon regeln :) ).

Zur Initialisierung würde ich von einer etablierten Library, wie erwähnt, nur unter zwingenden Umständen absehen. Die einmillionste Implementierung einer OpenGL-Fenster-Initialisierung braucht echt keiner, und ich schätze du hast genug andere Sorgen die erst mal aus der Welt geschafft werden müssen. Meine letzten Erfahrungen waren noch mit der SDL1.irgenwas, aber wenn die aktuelle SDL dir nicht schmeckt dann nimm halt GLFW oder sonstwas. Für den Anfang ist es ja auch erst mal vollkommen wurscht ob da irgendwelche Audio-APIs gelinkt werden die du dann nicht nutzt (sofern es denn trotzdem läuft). Dein OpenGL-Code ist nach der Initialisierung ja unabhängig von SDL (oder was auch immer). Das heißt die Lib lässt sich dann auch später noch durch was anderes ersetzen ohne das der Rest des Programms angepasst werden muss.

[Spiele Programmierer]

Bezüglich GLEE vom OpenGL-Wiki:

The project seems more or less defunct.

While there is activity in the Git repository on Sourceforge, there has not been a new official version and distribution in years. The recent activity could represent a project coming back, but currently you would be better advised to look elsewhere for an OpenGL loader.

Meiner Meinung nach ist SDL einfach prinzipiell die falsche Anlaufstelle, wenn man kein komplette Spieleframework mit eigenen Renderingsystem sucht.

[Sternmull]

Hm, der letzte Commit von GLEE ist auch von 2011, also sollte man das wohl wirklich besser meiden. Ich hab damals auch nur GLEW verwendet (das ist auch heute noch aktuell, hab grad nachgeguckt). Der Punkt an der Sache ist jedenfalls das man sich nicht vor Extensions fürchten muss. Die lassen sich leicht einbinden und man kann so an neues Zeug kommen ohne eine komplette neue OpenGL-Version vorauszusetzen.

[Schrompf]

Ich hab mir mal GLFW angeschaut, aber mir fehlt da eine kritische Funktion: Wechsel Fullscreen <-> Windowed. Grmpf. SDL kann das. SFML schau ich mir dann auch mal an, aber das fällt ja auch eher in die "komplettes Framework"-Kategorie.

[Spiele Programmierer]

Bei GLFW muss man dafür den Context neu erstellen. Wenn das für dich ein Todschlagargument ist, wird es schwierig. Ich habe aber meine Zweifel ob das bei SFML geht.
EDIT:
Du könntest dir auch noch FreeGLUT anschauen. Das ist auch kein aufgeblasenes Riesenframework. Andererseits sieht mit GLFW irgendwie moderner aus. GLUT geht ja ursprünglich auf ein ur-ur-alt Projekt von der Anfangszeit von OpenGL zurück.

[antisteo]

SDL benutzt du lediglich, um ein Fenster zu erstellen, das einen OpenGL-Kontext hat. Außerdem hast du eine plattformunabhängige Methode, um auf Controller, Joysticks, Tastaturen und Mäuse zuzugreifen. Ist der Kontext ein mal erstellt, verwendest du lediglich nach dem Aufruf der GL-Befehle die SDL_GL_SwapBuffers.

Zum Thema OpenGL ES auf Windows 7: Embedded Systems haben ihre eigene GLES-Bibliothek. Auf dem Desktop linkst du aber einfach gegen die stinknormale libGL. (MESA hat auch seine eigene GLES-Lib, aber die braucht man nur, wenn man mit EGL im Backbuffer rendern willst.) Du verwendest lediglich den GLES2.0-Header, um exakt die Schnittmenge zwischen OpenGL und GLES zu erhalten.

[antisteo]

OpenGL ES 2.0 wurde laut Wikipedia 2007 definiert. Soviel zum Thema "mindestens 10 Jahre" :-)

OpenGL 2.0 entstand laut Wikipedia am 7. September 2004. Fast 10 Jahre.
GLES ist lediglich der Standard, der aus OpenGL 2.0 die Funktionen rausschmeißt, die legacy sind (damit embedded-Treiber-Entwickler nicht so viel arbeiten müssen)

[dot]

Kleines Update: OpenGL 4.5 ist draußen und bietet allerlei Direct3D Compatibility Funktionalität, die dir wohl gefallen würde. Problem ist natürlich, dass es all das erst ab OpenGL 4.5 gibt...