OpenGL-Programm läuft nicht mit Flag -O
-
Hallo,
Ich habe mein C++ Programm bisher immer nur mit -Wall compiliert, keine Probleme. Wenn ich nun -O oder -O2 dranhänge, compiliert es einwandfrei, aber der 3D-OpenGL-Bildschirm bleibt unsichtbar, flackert höchstens einmal kurz auf. Die Hintergrundfarbe ist zu sehen (glClearColor), und die eingeblendeten 2D-Anzeigen sind ebenfalls sichtbar.
Ich benutze g++ 4.02 unter Suse 10.0, die OpenGL-Version ist 2.1. Das Programm arbeitet mit SDL. Irgendeine Erklärung?
-
compiliert alles ohne warnings durch?
-
compiliert alles ohne warnings durch?
Ja, natürlich. Zuerst einige nicht initialisierte Variablen, aber das war schnell behoben.Vielleicht noch ein kleiner Hinweis: Wenn ich in der SDL-kontrollierten Eventschleife ein Delay von 10 einbaue, ist der 3D-Screen am Anfang für einen Bruchteil einer Sekunde zu sehen, dann wird's monochrom und bleibt so.
-
Habe gerade noch eine Entdeckung gemacht. Bei dem Programm, das nicht läuft, hatte ich alle double-Variablen in GLfloat geändert, um besser mit OpenGL kompatibel zu sein (und Platz in den gewaltigen Arrays zu schaffen). Nun habe ich die Version mit double zurückgeholt und mit den Flags -O, -O2, -O3 getestet - läuft einwandfrei. Versteh' ich nicht.
-
hast vielleicht ein paar nicht sichere casts benutzt?
-
Es scheint so, als hätte es nichts micht OpenGL zu tun, wie ich zuerst dachte. Es ist wohl eine Frage des Typs. Bevor ich den ganzen Quelltext nach castings durchsuche, werde ich werde ich wohl schrittweise nach GLfloat ändern und so etwas eingrenzen. Danke.
-
du kannst ja .cpp fuer .cpp die optionen abaendern und testen ob es kaputt ist, so kann man zumindestens die datei eingraenzen in der das passiert.
unsichere castings waeren z.b. reinterpret cast auf float* von uint* um direkt uint auf float ohne convertierung wie bei static cast zu machen. wenn du das machen willst, musst du eine union benutzen. da ist gcc mit optimierungen recht brachial (was laut c++ standard auch legitim ist).
-
Manchmal hat man ein Brett vorm Kopf. Klar, man kann ja die Datei eingrenzen, indem man die Flags einzeln setzt. Verantwortlich war ausgerechnet die dicke Sammlung mit mathematischen Funktionen. Aber ein falscher Cast war's nicht, vielmehr eine Bereichsüberschreitung (unterschreitung). Um gelegentlich kleine Abweichungen von Null abzufangen zu können stand da
#define EPS 1.0e-13Das passt natürlich nicht mehr zu float. Mit
#define EPS 1.0e-7funktionierts. Danke.
-
Hat es einen speziellen Grund warum du dir dein EPS selbst definierst (auch noch als Makro, in C++, tststs ;)) und nicht FLT_EPSILON bzw. std::numeric_limits<float>::epsilon() benutzt?
-
Hat es einen speziellen Grund warum du dir dein EPS selbst definierst
Nee, ich habe die Math-Lib zum Teil übernommen (gibt es ja zuhauf für Vektoren, Matrizen, Quaternionen ...) und dabei sind einige Makros mit reingerutscht. Die Lib ist in C geschrieben, was ich grundsätzlich nicht für falsch halte, denn was z.B. Vektor-Klassen betrifft, so passen die nicht immer ins Konzept. Vieles habe ich schon überarbeitet, aber noch nicht alles.