Chemiestudium mit Linux und TeX

C++ – der 4. Versuch

Am Ende des letzten Semesters dachte ich, in den Semesterferien würde ich mehr Zeit damit verbringen, Wikipedia zu verbessern und mich näher mit Statistik zu beschäftigen. Mit dem Einstieg in die Statistik habe ich tatsächlich begonnen, jedoch schnell feststellen müssen, dass die Bücher, die ich mir dazu bestellt und ausgeliehen hatte, bereits zu viele Grundkenntnisse voraussetzen. Ein Buch zur statistischen Inferenz hat mich dann immerhin der Programmiersprache R nähergebracht. Kaum war ich jedoch beim Programmieren, hat es mich (zum mittlerweile vierten Mal in meinem Leben) in Richtung C++ gezogen. Dem Programmieren ging dieses Mal eine intensive Suche nach einer geeigneten Entwicklungsumgebung (IDE) voraus. Nachdem ich von Windows immer mehr Abstand genommen hatte und ich nach der Geburt meines Sohnes auch keine Zeit mehr mit Computerspielen verbrachte, verband mich nur noch Delphi mit Windows, wobei ich mich in letzter Zeit intensiver mit dem plattformübergreifenden Lazarus-Projektlink auseinandergesetzt hatte, mit dem ich beispielsweise auch die Monte-Carlo-Integration der Fläche des Reuleaux-Dreiecks und -Tetraeders durchgeführt hatte. Mit Lazarus als Vergleichsbasis hing die Messlatte relativ hoch, jedoch hatte ich mit Lazarus auch von Anfang an meine Probleme, denn die momentan noch schnelle Entwicklung des Projekts ist mit meinem Wunsch nach einem stabilen Betriebssystem (Debian Wheezy) nicht so recht zu vereinbaren, sodass ich mich doch nach Alternativen umsehen wollte. Zusammen mit der Tatsache, dass Pascal eine relativ exotische Sprache ist (die lediglich die Eigenheit besitzt, dass deutsche Schulen sie anscheinend lieben), war mir klar, dass ich nicht nur nach einer neuen Entwicklungsumgebung sondern auch nach einer anderen Sprache suchte. Die Entwicklungsumgebung sollte dabei natürlich nativ die Erstellung grafischer Oberflächen unterstützen.

Schaut man sich im Bereich freier Software einmal nach Bibliotheken für die Erstellung grafischer Oberflächen um, fallen besonders schnell GTK und Qt auf. Gewisse Interessanz hatte für mich auch wxWidgets, welches keine eigene grafische Oberfläche bietet, sondern gewissermaßen eine weitere Abstraktionsebene bildet und die native Bibliothek auf dem Zielrechner verwendet, um grafische Oberflächen zu erzeugen. Während ich die Idee eines Programms, dass sich in einer GTK-Umgebung so verhält, wie man es für GTK erwarten würde, auf einem Apple-Gerät so, wie es von Mac erwartet wird und auch unter Windows die native Oberfläche nutzt, fand ich die Vorstellung, dass gewisse Komponenten eines Programms sich in verschiedenen Umgebungen anders verhalten können, doch etwas abschreckend. Hinzu kam, dass ich keine IDE für wxWidgets finden konnte, sodass ich meine aktive Wahl auf GTK und Qt beschränkte. Da ich selbst Xfce als Desktopoberfläche verwende, welches auf GTK2 basiert, war ich zunächst eher geneigt, in Richtung GTK zu gehen. Nach einiger Recherche fand ich jedoch einiges über die enge Verzahnung mit Gnome und die (damit verbundenen?) ständigen nicht abwärtskompatiblen Änderungen in Minor-Versionen heraus, was mich dann doch sehr abgeschreckt hat.

Auch bin ich darauf aufmerksam geworden, dass sich LXDE mit dem Erscheinen von GTK3 von GTK abwendet und in Zukunft auf Qt basieren soll, was gleichzeitig mit einem Merge mit razor-qt einhergehen soll – eine Entwicklung, die ich äußerst spannend finde, da ich aus der Linux-Welt bisher immer nur von Forks gehört hatte; bei Desktopoberflächen insbesondere von den vielen Gnome-Forks, die es seit dem Erscheinen von Gnome 3 (welches mich erstmal für zwei Jahre von Linux fortgescheucht hatte, bis ich mich dann von Windows so eingeengt fühlte, dass ich schließlich zu Xfce fand) gab: Unity, Mate, Cinnamon, … Wenn dann (in ferner Zukunft?) einmal LXQt-Pakete für Debian zur Verfügung stehen sollten, werde ich es mit Sicherheit ausprobieren. Bis dahin übe ich mich aber in Geduld und freue mich, dass ich mit meinem Xfce/Debian-System endlich mal nicht die Semesterferien damit verbringen muss, meinen Rechner neu aufzusetzen (zumindest nicht meinen Arbeitsrechner).

Zurück zu C++ und Entwicklungsumgebung: Nachdem ich dann noch mehr über GTK vs Qt gelesen hatte, entschied ich mich schließlich für Qt, wobei ich es sehr praktisch fand, dass es dafür mit QtCreator auch eine IDE gibt, die ich mit einem simplen
aptitude install qtcreator
installieren konnte. Als erste Übungen schrieb ich ein simples Hello-world-Programm und ein Zahlenraten.

Schnell hatte ich ein erstes großes Projekt gefunden, das für die ersten Versuche, mit einer Sprache, einem Framework und einer Entwicklungsumgebung gleichzeitig klarzukommen sehr hoch angesetzt ist, denn ich setzte dem Ganzen nämlich noch eine Programmierschnittstelle oben drauf: OpenGL – und da wir im Jahr 2014 leben, natürlich nicht im Immediate-Mode, in dem man die CPU damit beansprucht, ständig der Grafikkarte mitzuteilen, wo der nächste Vertex (Eckpunkt) des zu zeichnenden Dreiecks liegt, welche Normale, Farbe und Texturkoordinate ihm zugeordnet sind, während sich die GPU-Kerne langweilen und Däumchen drehen. Ich hatte schon vor, es in modernem OpenGL zu programmieren. Die ersten Versuche, einen Shader zu programmieren und zu kompilieren endeten dann jedoch mit einem schwarzen Bild, auf dem weiße Dreiecke zu sehen waren. Das Debugfenster hatte dazu Folgendes zu sagen:
GLSL 3.30 is not supported. Supported versions are: 1.00 ES, 1.10, and 1.20
Man muss dazu sagen, ich programmiere auf einem Dell Inspiron 1525 mit Intel Core 2 Duo T5750. Die 2×2.0 GHz sind für meine Zwecke in der Regel mehr als genug (auch wenn Firefox/Iceweasel mit 120 Tabs nicht mehr ganz flüssig läuft^^). Da ich den Rechner im August 2008 aber nicht zu dem Zweck gekauft hatte, 3D-Spiele zu spielen, habe ich auf eine dedizierte Grafikkarte verzichtet und mich mit dem eingebauten Intel GM965-Modul zufriedengegeben. Angesichts der Tatsache, dass GM965 nur OpenGL 1.5 unterstützt, finde ich es schon erstaunlich, dass es überhaupt mit Shadernwiki und GLSLwiki zurechtkommt, insbesondere da Intel ja nicht dafür bekannt ist, dass es sonderlich großzügig bei der OpenGL-Unterstützung ist (beispielsweise unterstützen Sandy-Bridge-Prozessoren von Anfang 2011 jetzt endlich die 2009 veröffentlichte OpenGL-Version 3.2Quelle. Nachdem ich das herausgefunden hatte, musste ich mich dann erstmal auf GLSL 1.10 beschränken (1.20 brachte keine bahnbrechenden Änderungen, sodass ich darauf verzichten konnte). Die Beschränkung auf GLSL 1.10 hatte einige hässliche Workarounds zur Folge, die aber andererseits auch ein wenig Kreativität forderten. Vielleicht erzähle ich ein anderes Mal mehr darüber.

Über das Projekt will ich aktuell nur so viel verraten: Es handelt sich um ein rundenbasiertes Spiel, in dem es mehr um Glück als um Verstand geht. Durch die Programmierung habe ich neben einer kleinen Einarbeitung in altes GLSL (bisher etwa 70 Zeilen) auch C++ kennengelernt (das Projekt zählt aktuell neun Klassen und etwa 2000 Zeilen Code) und das Signal-Slot-Konzept von Qt kennen und schätzen gelernt. Im gleichen Zug habe ich es geschafft, so abhängig von Signalen und Slots zu werden, dass ich sie auch unter Umständen verwenden will, unter denen sie nicht funktionieren… aber dazu mehr in meinem nächsten Post.

Comments are closed.