WhyOpenGL
(Mehr Informationen/weitere Artikel) {{{1}}} |
 |
Phobeus: Dies soll nur ein Stub sein und zur Ideensammlung dienen / Wir haben sehr viele Leute im Netz rumlaufen, die noch denken, dass DelphiX das absolute Non-Plus-Ultra ist. Ich würde gerne einen Artikel haben um einige gänige Fragen zu beantworten.
Inhaltsverzeichnis
Warum OpenGL?
Allgemein
OpenGL läuft auf einer Vielzahl von Platformen. Während DirectX (sowie darauf basierende Schnittstellen wie DelphiX) auf Microsoft Windows beschränkt ist, wird OpenGL u.a. auch von Linux, FreeBSD und Macintosh unterstützt, was evtl. Portierungen erleichtert. OpenGL ist auch nicht nur auf PC sondern auch auf PDAs, Apple, Java-Handys und einigen Konsolen nutzbar. So ist die OpenGL Library bei Windows, MacOS X und Linux (gängige Distributionen) schon standardmäßig dabei und braucht nicht erst installiert werden.
OpenGL besteht aus einer Library und soll nur ein Ziel erreichen, nämlich eine gute und performante API für das Ansprechen der Grafikkarte und ihren Komponenten. Die Implementierung ist dementsprechend einfach, denn es existiert nur eine DLL im Gegensatz zu der Librarysamlung von DirectX. Die Benennung der einzelnen Funktionen ist leicht herleitbar und übersichtlich. So fängt eine OpenGL Funktion immer mit GL... an und beschreibt dann die Funktionsart, wie z.B. Begin, End, BindTexture und weitere.
Hinter OpenGL steckt eine Firma namens SGI, die diese API 1992 veröffentlichte. Seither arbeiten an OpenGL zahlreiche Vertreter der Grafikindustrie wie Nvidia, ATI, IBM, HP und andere Groß- und Kleinunternehmen aus allen Branchen.
Im Gegensatz zu DirectX ist es den Grafikkartenherstellern mit OpenGL möglich, eigene Funktionen, die an die eigene Hardware angepasst ist, zu vorhandenen Befehlen mit in die Libary einzulagern (sogenannte Extensions). Dies ermöglicht bei Anwendung erhebliche Performancesteigerungen und kann mitunter sogar Features die sonst brach liegen zur Verfügung stellen. So kann man mit OpenGL die TrueForm Technik gut ausnutzen und ungewollte Aufwertung unterbinden.
Bei 2D-Anwendungen?
In den letzten Jahren sind 2D-Anwendungen mitunter sehr aus der Mode gekommen. Wer sich heutzutage ein Spielemagazin kauft und die Seiten durchblättert wird unter den Top-Titeln nahezu ausschließlich 3D-Titel finden. Doch nicht immer ist 3D auch wirklich notwendig bzw. bei einem Projekt sinnvoll. Bewußt möchten manche Autoren ein 2D-Spiel machen und greifen dabei schon fast aus Protest zu einer alten Schnittstelle. Aus diesem Grund geistern vermutlich noch soviele Leute durchs Netz und wenden DelphiX an, dass bereits auf eine DirectX-Version basiert, die seit graumer Zeit veraltet ist. Solange man nur wenige Bilder versucht auf dem Bildschirm zu zeichnen, scheint dies auch noch ausreichend zu sein.
Allerdings kommt auf kurz oder lang dann doch die Frage auf, wie man die Performance verbessern kann. Gerade wenn es darum geht viele Objekte transparent zu zeichnen, kommt sehr schnell Frust auf, wenn die FPS-Rate in den Keller sinkt. Der Grund hierfür liegt dabei auf der Hand. Alte Schnittstellen verwenden nicht die neue Hardware und so kommt es dazu, dass die neue Grafikkarte nicht genutzt wird, sondern die Grafiken über die CPU geschleift werden. Wer also eine 2D-Anwendung erstellen möchte, sollte sich folgende Szenarien einmal zu herzen nehmen.
Pseudo-3D
Früher wurde versucht mit Hilfe einer isometrischen Engine eine 2D-Grafik so ausehen zu lassen als sei diese eigentlich dreidimensional. Ich denke jeder von Euch hat bereits einmal SimCity oder Jagged Alliance gesehen und kann sich in etwa vorstellen, was unter einer ISO-Engine verstanden wird. Eine solche Technik in der heutigen Zeit einzusetzen ist meistens eher hinderlich als produktiv. Man stelle sich nur einmal eine Figur darauf vor, die sich in mehre Richtungen bewegen kann. Für jede Bewegungsrichtung müßte man bei reinem 2D eine Grafik bereit halten (und sei es nur im Speicher). In einem 3D-Raum könnte man einfach ein Modell nehmen und dieses wirklich von mehren Seiten betrachten. Würde man nun auf die Idee kommen die Kameraeinstellung um nur wenige Grad zu drehen, würde dies einer kompletten Neuerstellung aller Grafiken zur Folge haben.
Verwendet man statt dessen einen 3D-Raum mit einer Kamera, die nur nach oben, unten, links und rechts verschoben wird und ansonsten immer in einem festen Winkel auf das Spielfeld blickt, so erhält man einen ähnlichen Effekt wie bei einer isometrische Engine. Der Vorteil, dass zahlreiche mathematische Operationen nur im 2D-Raum berechnet werden müssen, bleibt ebenfalls weiterhin erhalten. Dafür werden die Grafiken allerdings weitesgehend von der GPU berechnet, und es werden zahlreiche transparente Effekte zugelassen.
Orthogonale Grafik
Doch selbst wenn man nur eine reine 2D-Grafik wünscht wie sie vor 15 Jahren noch üblich war, bietet es sich an eine moderne 3D-Schnittstelle wie OpenGL zu verwenden. Dies mag auf den ersten Blick nicht logisch erscheinen. Allerdings macht dies Sinn, wenn man sich bewusst wird, dass die Grafiken bei OpenGL über die GPU der Grafikkarte geschickt werden, die meistens um ein vielfaches leistungsfähiger als die CPU ist (und diese ja auch mit anderen Berechnungen wie z.B. der KI beschäftigt). Zeichnet man stattdessen ein Quadrat und klebt eine Textur in Form der gewünschten Grafik darauf, erhält man ebenfalls den gewünschten Effekt.
Es mag nun kompliziert klingen in einem 3D-Raum Quadrate zu plazieren und zu texturieren. Man sollte allerdings wissen, dass es einen sogenannten orthogonalen Modus gibt in dem man bei einem 3D-Raum die Tiefe entfernt und somit wieder einen 2D-Raum erhält. Mit Hilfe des Tiefenbuffers kann man nun sogar noch die Z-Werte verwenden um die Zeichenreihenfolge der Quadrate zu bestimmen. Ein Tutorial zu Verwendung dieser Technik findet Ihr hier. Ausserdem sind alle nötigen Befehle hier in diesem Wiki (auf Deutsch) oder in euerer Delphihilfe (Englisch) bzw. im Netz (Englisch) dokumentiert.
Alternativen
Direct X
DirectX ist wohl die stärkste Konkurrenz zu OpenGL. Rein technisch sind beide Schnittstellen quasi ebenbürtig. Viele merkwürdige Gerüchte halten sich allerdings stets, z.B. das einer der APIs viel schneller sei als die andere oder ein merkwürdiges "Flackern" verursachen würde. Zweifelsfrei haben diese Beobachtungen Ihren Ursprung im Bereich von Hybrid-Engines, die beide Schnittstellen benutzen. Meistens konzentriert sich der Entwickler hauptsächlich auf einer der Schnittstellen und entsprechend fehlerhaft wird die andere implementiert.
Die Tatsache, dass DirectX stärker verbreitet und somit besser sein muss, steckt in vielen Köpfen fest. Immerhin muss man bedenken, dass sehr viele Spiele auf der Quake-Engine aufbauen, die auf OpenGL setzt und auch Doom3 wird sicherlich ein guter Beweis sein, dass OpenGL mitunter nicht technisch veraltet ist. Warum also ist DirectX gerade bei Spieleherstellern sehr verbreitet? Die Ursache hierfür liegt wohl darinne, dass neben der reinen Grafik-API auch zahlreiche Lade-Funktionen bereit gestellt wird und man diese bei der Verwendung von OpenGL manuell implementieren muss. In der Praxis ist dieser kleine Schönheitsfehler (wenn man mehr Kontrolle als solches bezeichnen möchte) mitunter zu vernachlässigen, da es zahlreiche gute Loader gibt, die hierfür einen Ersatz schaffen. Auch mit dem stärkeren Aufkommen von SDL gibt es ein Gegenstück zu DirectX, dass harmonisch mit OpenGL zusammenarbeitet.
Der Hauptnachteil von DirectX liegt vorwiegend darin, dass diese Schnittstelle von Microsoft gefördert wird. Es versteht sich von selbst, dass man dies als Vor- oder Nachteil werten kann. Der Vorteil von wenigen Stimmberechtigten bedeutet, dass auch schnell Entscheidungen getroffen werden. Entsprechend flexibel können Veränderungen eingebaut werden. Der Nachteil kann darinne bestehen, dass sich Teile der Initalisierung oder der zu grundelegenden Technik ebenfalls sehr schnell verändern kann (man Vergleiche dazu DX7, DX8 und DX9). OpenGL hat sich quasi seit 1992 nicht in seiner Grundform verändert, sondern wurde stets nur erweitert oder im Unterbau an neue Technologien angepaßt. Dies bedeutet also, dass das gelernt Wissen vermutlich länger eingesetzt werden kann.
Einer der wohl wirklich herausragensten Nachteile von DirectX ist, dass es nur auf der Windows-Plattform zu Hause ist und es nur sehr schwer möglich ist, seine Software auch auf anderen Systemen anzubieten. Dies liegt u.a. darin begründet, dass DirectX eine Objekt-orientierte API ist, was in dieser Form durch Windows-spezifische Elemente ermöglicht wird, während OpenGL eine prozedurale API ist und deshalb auf wesentlich mehr Systemen verbreitet ist. OpenGL wurde von Anfang an dafür entwickelt auf anderen Plattformen zu laufen und zusammen mit SDL stehen einem ohne zusätzlichen Aufwand fremde Plattformen wie Macintosh oder Linux (theoretisch sogar Playstation ;)) für die eigenen Anwendungen zur Verfügung. Dies mag den Hobby-Entwickler sicherlich eher weniger interessieren, allerdings sollte man stets daran interessiert sein das Publikum für seine Anwendungen möglichst groß zu halten. Wer Interesse an der Verwendung von DirectX mit Delphi hat, sollte einmal unser "Gegenstück" besuchen: www.delphidev.de
DelphiX
Ist eine Komponentensammlung, die den Zugriff auf DirectDraw kapselt. Was vor entlichen Jahren noch eine hervorragende Angelegenheit war um unter Delphi Grafiken zu zeichnen, ist inzwischen zu einer Lösung verkommen, die man eigentlich nicht als Alternative mehr bezeichnen darf. DelphiX basiert weitesgehend noch auf DX7 und wird bereits seit Jahren nicht mehr von seinem Autor gepflegt. Zahlreiche alte Fan-Projekte versuchen die Komponentensammlung am Leben zu erhalten - teils mit eher mässigen Erfolg. Denn nicht nur an der Wartbarkeit hapert es. DelphiX ist aus technischer Sicht gänzlich veraltet und nutzt die Hardwarebeschleunigung der Grafikkarte nicht. Kaum ein Monat vergeht in denen in einschlägigen Foren nicht die Frage von verzweifelten Programmiern kommen, warum das intensive Verwenden von transparenten Gebilden die Leistung des Rechners nach unten drückt.
Warum scheint DelphiX dennoch so weit verbreitet zu sein? Vermutlich liegt es daran, dass es vor einigen Jahren die einfachste Möglichkeit war unter Delphi Grafiken zu zeichnen und es auch heute noch sehr simpel erscheint eine Komponente auf ein Formular zu ziehen und sich nicht näher um die Initalisierung der Schnittstelle kümmern zu müssen. Allerdings unterliegen damit gerade Anfänger dem Irrglauben dadurch professionelle Titel leichter zu schreiben könnnen. Den dazu gehört ein solides Hintergrundwissen, so dass man keineswegs darum herumkommt dieses Wissen dennoch zu erwerben. Besonders fatal an DelphiX ist eigentlich, dass es weder mit DirectX noch mit einer anderen Schnittstelle etwas gemeinsam hat. Es zu erlernen hat zur Folge, dass man für den Papierkorb lernt. Daher sollte vor dem Erlernen von DelphiX in jedem Fall geprüft werden, ob es nicht sinnvoller ist zu einer Alternative zu greifen. In den meisten Fällen wird sich hierbei OpenGL oder DirectX anbieten. Sollte wirklich nur reines 2D ohne zeichnen vieler transparenter Objekte benötigt werden, stellt auch reines SDL eine sinnvolle Alternative da.
Bitte verwendet unter gar keinen Umständen die 3D-Schnittstelle von DelphiX. Diese basiert auf den sogenannten "Retained Mode" von Direct3D und wurde bereits mit DX7 von Microsoft aus DirectX entfernt. Dieser Modus ist nicht nur wesentlich langsamer als richtiges Direct3D, sondern nutzt auch die neueren Errungenschaften moderner Grafikkarten nicht. Sein Lernen ist in jedem Fall eine Arbeitsleistung für den Papierkorb.
GLScene
SDL
SDL als Alternative zu OpenGL zu bezeichnen ist im Ansatz bereits ein wenig fehlerhaft, da diese beiden Schnittstellen eigentlich in keiner direkten Konkurrenz stehen. Ganz im Gegenteil ergänzen sich diese beiden gegenseitig hervorragend. SDL übernimmt die Verwaltung für das Zeichenfenster, die Eingaben des Benutzer und hilft beim Laden von Texturen, während OpenGL als die Schnittstelle verwendet wird um die Grafik auf den Bildschirm zu rendern. Dennoch führen wir SDL hier als Alternative zu OpenGL auf, da es mit SDL ähnlich wie mit DirectDraw möglich ist reine 2D-Operationen auf den Bildschirm zu zeichnen. Dies erfolgt allerdings ohne Hardwarebeschleunigung und es sollte deutlich zuvor geprüft werden, ob man darauf wirklich verzichten möchte und nicht zu einem der oben vorgestellten "Pseudo-3D"-Tricks greifen möchte.
