FinalFantasy schrieb am 05.08.2021 19:33:
OpenGL war nicht auf Spiele ausgelegt, sondern auf professionelle Anwendungen, CAD, Renderings, etc. Deswegen hat 3dfx ja auch das Zeug rausgeworfen, was man für Spiele nicht brauchte oder die günstige Mainstreamspielehardware eh nicht konnte.
Das hatte ich doch im Grunde auch schon geschrieben und es steht auch nicht im Widerspruch zu irgend einer Aussage von mir, denn auch wenn OpenGL viel Zeug mitbringt, das man für Spiele nicht braucht, ist ja niemand genötigt das zu verwenden nur weil es vorhnaden ist und muss eine Implementierung diese Funktionen dann auch nicht gut oder schnell umgesetzt haben, denn Spiele werden sie eh nicht nutzen und Software, die sie nutzt, wird nicht so performancekritisch sein.
Da kann man sich dann vorstellen, was OpenGL für ein riesen Klotz ist.
OpenGL ES ist nicht entstanden, weil OpenGL ein großer Klotz ist, was es nicht ist (wir reden hier von ein paar KB, jede Standard C Library ist größer), hier ist die komplette OpenGL 1.1 API, von der Glide aus damals gebaut wurde:
https://www.khronos.org/registry/OpenGL/specs/gl/glspec11.pdf
Hier als online Version:
http://www.glprogramming.com/red/
Da ist zwar viel Text und viel erklärt, aber wie man sieht sehr wenig Code und API.
OpenGL ES ist entstanden, weil schwache Mobilgeräte abgespeckte Funktion brauchten, z.B. 565/5551 RGB(A) statt 888/8888 RGB(A) oder Integer Coordinaten statt Floating Point Werte (die ersten Mobil-CPUs hatten gar keine FPU Einheit und FPU in Software wäre viel zu langsam gewesen) und weil so eine einfache Funktion wie Textrendering auf vielen dieser Geräte nicht möglich gewesen wäre (die hatten gar keine TrueType Font Engine; Font war oft Bitmap).
Die meisten Änderung dienten dazu RAM zu sparen, denn das war noch vor Rechenleistung der Knackpunkt (GPU und CPU teilen sich hier das RAM, es gibt grundsätzlich wenig und das meiste davon brauchen OS und Apps bereits selber). Daher wurde auch Texture-Kompression fester Teil von ES, während es beim normalen OpenGL lange optional und nur als Erweiterung verfügbar war.
Nicht die Geschwindigkeit der Ausführung, sondern die Geschwindigkeit mit der man Software damit entwickeln kann.
Und die ist sehr hoch. Mit nur 200 Zeilen App Code habe ich schon animierte 3D Grafiken auf dem Schirm. Mit 200 Zeilen Vulkan oder Direct3D habe ich gar nichts. Das reicht nicht mal für das Setup.
Das liegt daran, dass man OpenGL nur sagen muss, was man gerne von ihm möchte und nicht was OpenGL jetzt konkret tun muss oder wie er das bewerkstelligt. Im Grunde beschreibt man OpenGL eine Szene und sagt "So und jetzt zeichne mal" und ab da hat OpenGL dann freie Hand. Genau das war ja die Stärke der API: Der Implementierer hat hier extreme Freiheiten in der Umsetzung. Das ist auch der Grund, warum man OpenGL problemlos als Direct3D-, Vulkan- oder Metal-Wrapper implementieren kann (alle diese APIs sind dazu geeignet OpenGL umzusetzen). Umgekehrt ist manchmal ein Problem, denn die anderen APIs geben teilweise genau vor, wie etwas zu passieren hat und genau das kann man bei OpenGL aber oft nicht tun (man kann dann etwas machen, das so ähnlich aussehen sollte, aber man kann hier nicht immer exakt den Standard erfüllen, außer durch komplexe Shader und die werden langsam sein).
Wir können ja gerne einen Wettbewerb starten. Ich poste hier ein voll lauffähiges OpenGL Sample, das schöne 3D Grafiken auf deinem Schirm zeichnest und du zeigst mir mal, wie man das mit Vulkan oder Direct3D angeblich einfacher hinbekommt und dann lassen wir darüber abstimmen, welcher Code einfacher ist (denn welcher kleiner ist, steht schon fest und das sieht ja auch jeder sofort). Nur so zum Spaß würde ich dann sogar noch anbieten, eine Metal Version davon zu erstellen, nur weil mich mal interessieren würde, was Laien sagen, wenn sie mal Vulkan und Metal Code Seite an Seite sehen; wäre interessant, ob die dann immer noch der Meinung sind, das Vulkan so eine geile API ist, unter der Annahme, dass sie selber den Code schreiben würden.
/Mecki