Ich habe ein kleines OpenGl-Programm programmiert, habe aber das Problem das Grafikfehler auftreten. Der Grafikfehler ist, dass Flächen mit Texturen gezagt dargestellt werded (obwohl es nur eine Fläche ist). Weiß jemand wie man das verhindern kann? (Das Problem trifft bei meinem 3200er zu Hause nicht zu, aber bei meinem alten 233er und den 1500er Schulrechnern auch).

Das zweite Grafikproblem, das ich bei OpenGl habe, ist, wenn ich mit Listen arbeite (die sollen ja schließlich teilweise schneller arbeiten), dass ich mindestens in der Zeichenprocedure noch so zeichnen muss, da sonst graue Streifen über das Bild noch flackern (der wechselt dauernd zw. dem eigentlichen Bild und einem grauen Bild ohne das ich einen Grund kenne).

Das zweite Problem entsteht, wenn du das ganze Form aktualisierst, dann zeichnet er zuerst den grauen Hintergrund und dann das was darüber ist, das müsste sich mit Form.doublebuffered:=true lösen lassen. Was du mit dem ersten Problem meinst weiß ich nicht. Wie wärs mit nen paar Screenshots?

wenn du mir sagst wo ich das Bild ablegen kann (habe keine Internetseite wo ich das ablegen könnte).

Kann es sein, dass in den anderen beiden Rechnern nur die "alte" Version von OGL auf den Grafikkartenchips implementiert ist und du eine "zu neue" verwendest?

AXMD

Frag doch mal bei Freunden oder Bekannten nach. Wenn nicht, dann such doch mal im Forum, da gabs etliche Beiträge zu Webspace.

Wie bekommt man raus, für welche OpenGl-Versin die Grafikkarte taugt??
Bei meinem alten Rechner läuft die OpenGl12.pas, die dglOpenGl.pas dagegen nicht, dadurch denke ich mal das die Grafikkarte die OpenGl12.pas auch unterstützt (die Grafikfehler treten nur auf wenn ich Texturen einbinde mit dem texturenloader von dem Tutorial "OpenGl - Einführung").

@sourcehunter: welche Freunde und Bekannte?
Bekannte kenne ich keine die mit Delphi programmieren (würden auch zuweit weg wohnen um mit denen zu kommunizieren) und meine Freunde programmieren nur das "Schuldelphi" (es programmiert nur ein anderer in seiner Freizeit und der mit C/C++).

Aber zu dem Problem: würde vielleicht auch CreateRenderingContext den Fall verbessern (kann es gerade nicht ausprobieren, da ich in der Uni-Bibo bin)??
Form1.DoubleBuffered.true will ich nicht verwenden, da bei meinem alten Rechner, wo ich diesen Befehl ausprobiert hatte das Formular nicht mehr erschien (soweit ich mich erinnere hatte er das Programm sogar beendet).

AXMD hat folgendes geschrieben:

Kann es sein, dass in den anderen beiden Rechnern nur die "alte" Version von OGL auf den Grafikkartenchips implementiert ist und du eine "zu neue" verwendest?

Nein, die Grafikchips implementieren keine Grafikbibliotheken, sondern nur die entsprechenden Features. Die Treiber sind es, die das eigentliche Interface bereitstellen und dann entweder in Hardware oder in Software implementieren. Evtl mal ein Treiberupdate versuchen?

Hi. Zwischen der OpenGL12.pas und der dglOpenGL.pas besteht lediglich der Unterschied, dass die etwas anders aufgebaut sind und die dglOpenGL.pas mehr features unterstützt. Wenn deine Karte diese Features nicht unterstützt, dann kannst du sie lediglich nicht verwenden. Ich denke also mal, dass du bei der Implementation der dglOpenGL.pas einen Fehler gemacht hast.

Aber zu den Darstellungsfehler. Ich verwende OpenGL ständig ohne irgendwelches Zutun von DoubleBuffering oder sonst etwas. Und bei mir entstehen keine solche Probleme. Aber um dir dort ernsthaft helfen zu können musst du entweder ein paar Bilder und ein bisschen Code springen lassen. Sonst können wir nur raten wo dein Problem liegt.
Zum Thema Speicherplatz. Schicke mir deine Bilder per Mail (Siehe PM) und ich lade sie hoch.

Ich meinte eigentlich, dass du deine Freunde oder Bekannte einfach mal fragst, ob sie dir etwas von ihrem eventuell vorhandenem Webspace abgeben, damit du dein Bild ins Internet stellen kannst.

Nein, also das DoubleBuffered ist hier zweifelsfrei ganz weit ab von Schuss. Um den Fehler sinnvoll festzustellen, wirst Du ihn auch weiter isolieren müssen. Die DGL-Header sollten problemfrei auf allen Grafikkarten laufen, zumindest solange die Treiber entsprechend taugen (und diese zu Updaten bewirkt häufig wunder bei merkwürdigen Problemen). Aber gezackte Texturen? das hört sich für mich spontan nach etwas ganz anderen an, nämlich zu eng aufeinander liegende Vertices. Kann es sein, dass Du zwei Quads exakt aufeinander zeichnest? Das ist nicht gesund für den Tiefenbuffer und kann zu solchen Effekten führen. Da helfen je nachdem, was man erreichen will, zwei Ansätze: 1. Den Abstand vergrößern (sehr gering 0.001 z.B.) oder die Tiefe des Buffers erhöhen (was meist bedeutet an die Grenzen des Grafikkarte zu stoßen *g). 2. Wenn Du Versuchst einen Effekt z.B. beim Blending zu erreichen, entsprechend den Tiefenbuffer deaktivieren. GLDisable(GL_DEPTH_TEST);
Das zweite Problem klingt für mich doch sehr sonderbar. Ich würde rein emotional in der Richtung suchen, dass der ColorBuffer falsch auf die Leinwand gebracht wird. Um dieses Problem auszuschließen, bitte ich Dich mal darum auf unserer Seite (mein Profil) das entsprechende Template herunter zu laden und in der Draw-Procedure deine Listen zu rendern. Sollte das Problem dann immer noch vorhanden sein, entsprechenden Code bitte ebenfalls einmal Posten.

Hier der Grafikfehler mit der Fehlerhaften Wand (das ist wirklich nur eine Wand), die wo die Zeckung noch deutlicher Auftritt habe ich nicht ganz getroffen, da der alte Rechner so stockt, dass ich an dieser Position vorbeigerant bin.

Also ich sage es nur ungern. Aber auf dem Bild kann man das nicht so sonderlich gut erkennen. Man könnte fast meinen, dass es so gewollt wäre.

Aber davon mal abgesehen. Ich denke mal ich habe eine Vermutung was bei dir das Problem ist. Bei der Demo von Unreal Tournament 2 hatte ich auf meinem System auch mal solche Probleme. Ich denke das Problem hängt mit der Konfguration deines Tiefenbuffers zusammen. Also ich schätze mal, dass du auf diesem System einen Tiefenbuffer von 16 Bit hast und eine unglückliche geählte Sichtweite verwendest.
Und zwar die Parameter zNear und zFar bei gluPerspective. Wenn du zNear zu klein machst, dann verbraucht er im unteren Bereich (ist ja näher am Betrachter) mehr Speicher und hat somit für Dinge die Weiter weg sind nicht mehr genügend Speicher. Dementsprechend wird die Auflösung kleiner und es können solche Stufen entstehen. Abhilfe kann entweder ein verändern der Sichtweite oder erhöhen des Tiefenbuffers auf 32 Bit schaffen. Allerdings denke ich mal, dass ein Tiefenbuffer von 32 Bit nicht auf jedem System optimal ist. Zwecks Speicherauslastung. Und die Grafikkarte kann sich immer noch dagegen wehren.

Erstmal zum Verständnis deines Bildes:
Das rote ist die Decke, das schwarze der Fußboden und das graue soll die Wand sein, oder?

Wie hast du denn die Wand rendern lassen? Ist das ein Quad? Oder mehrere?

Hier das Programm in dem die beiden aufgetretenen Grafikfehler sind (um den 2. Fehler zu erzeugen entfernt mal aus der Zeichenprocedure die Prozedure Figur(...)).

Kann sein, dass ich jetzt keine weiteren Fehlerhaften Bilder zeigen kann, da das Programm seit kurzem (nach einer Änderung im Programm, ich weiß aber nicht welche Änderung das war die ich eingefügt habe) am alten 233er Rechner gar nicht mehr läuft, am 3200er Rechner der erste Grafikfehler nicht auftritt und ich in der Schule sehr selten an den Rechner komme.
Ich habe jetzt mal die den Aufruf der Zeichenprocedure in einen Thread ausgelagert, dann tritt der erste Grafikfehler auch wieder auf, obwohl nur der Ort des Aufrufes geändert wird (HauptForm -> Thread).

Heiko hat folgendes geschrieben:

Ich habe jetzt mal die den Aufruf der Zeichenprocedure in einen Thread ausgelagert, dann tritt der erste Grafikfehler auch wieder auf, obwohl nur der Ort des Aufrufes geändert wird (HauptForm -> Thread).

Versteh das bitte nicht falsch. Aber das kann ich ehrlich nachvollziehen! Ich habe den Code mal überflogen und habe so einige Sachen gesehen die alles andere als gut gelöst sind.

1.
braucht nur aufgerufen zu werden, wenn sich das Fenster ändert. (Bzw. zu Begin) Auf keinen Fall in jedem Frame. Das tust du in der Procedure Welt nämlich nach dem Löschen. Da sollte ein langweiliges glLoadIdentity vollkommen ausreichen. In dem Block in der Methode Welt übergibst du an gluPerspective auch andere Werte als in InitGL. Dadurch kann es sein, dass dein Problem auf dem alten System nicht weggegangen ist. Weil du nämlich immer noch die selben Werte übergeben hattest.

2. Deine Zeichenmethode ist äußerst Suboptimal! Wie wäre es wenn du anstelle von dem Timer und der Renderschleife einfach das Event Application.OnIdle benutzt. Done auf False und dann einmal zeichnen. Dann sollte es das gewesen sein. Fals nicht (oder auch noch zusätzlich) solltest du die Message WM_ERASEBKGND überschreiben. Wenn du Message.Result auf Integer(True) setzt glaubt Windows, dass du das Fenster bereits gelöscht hast und unterlässt alle sonstigen Zeichenoperationen. Außerdem solltest du in OnPaint die Welt nicht noch einmal Zeichnen. Oder du drehst es um und zeichnest nur in dem OnPaint und rufst aus OnIdle Repaint auf. Das geht auch.

3. Schau dir auch mal die Methoden glGetError und gluErrorString an. Das sollte normal and das Ende deiner Zeichnenmethode. So kannst du feststellen ob OpenGL der Meinung war, dass es Fehler gegeben hat. Stacküberlauf, Stack leer oder sonst etwas.

PS: Es wäre evtl auch hilfreich, wenn du dir das ein oder andere Tutorial und Template auf [url]www.DelphiGL.com[/url] anschauen würdest.

zu 1. Das hat mir auch schon ein Schulkamerade gesagt, der mit C++ OpenGl programmiert, hatte aber noch nicht die Zeit es umzusetzten. Ich soll also statt diesem Block nur noch glLoadIdentity verwenden (wenn ich dich richitg verstanden habe) und die Zeichenflächegröße bei Onresize nur noch verwenden.

zu2. Ich hatte ja bereits geschrieben, dass ich die Renderprozedur in einen Thread auslagern will (ich vertraue den Delphikompenenten nicht vollständig, wodurch ich OnIdle noch nicht ausprobiert habe)

zu PS. Daher habe ich ja das meiste (auch den das alles in der Renderprozedur zum Anfang noch mal aufgerufen wird), aber das meiste habe ich bei mir nicht hinbekommen (deswegen habe ich z.B. die Bewegungsroutine selber geschrieben, statt Vektoren zu verwenden, da das mit den Vektoren bei mir nicht funktioniert hat; das ambiente Licht bekomme ich bei diesem Programm nach Tutorial aber auch nicht hin)

Also das in einem Thread zu lösen ist nicht gut. Hatte ich schon mal gemacht und lass es dir gesagt sein. Bringt mehr Nachteile als Vorteile, da alles im Thread ablaufen muss. Da synchronisierst du dich dusselig und dann gibt es immer noch merkwürde Effekte. Also das mit Threads würde ich nur selten empfehlen.

Also eigentlich wollte ich meinen Code mal Posten. Aber ich fand das ein bisschen viel. Also als richtiges Projekt.
Das Ganze arbeitet allerdings mit der dglOpenGL undnicht wie deines mit der OpenGL12.

Muss ich mal ausprobiern mit der dglOpenGl.pas. Dass ich die bisher nicht verwendet habe, leigt daran, dass die Texturen-Unit unter dieser OpenGl-Unit nicht funktioniert und ich noch nicht die auf der delphigl-Seite vorgestellten Texturloader ausprobiert habe.
Ich habe dafür die Fehler mir mal ausgeben lassen. In der Prozedur Figur tritt ein Fehler des Typs GL_INVALID_OPERATION auf, obwohl ich keinen Grund für diesen Fehler sehe. Was ich am meisten verwundert ist, wenn ich die Figurenprozedur ausklammere ich kein Fehler (nach z.B. SwapBuffers) zurückgegeben bekomme, aber dafür der zweite Grafikfehler auftritt (wenn die Prozedur nicht ausklammere gibt mir OpenGl zwar den Fehler zurück, aber es kommt nicht zu dem Grafikfehler); und ich bekomme dazu noch eine Fehlermeldung (siehe Dateienanhang).
Zur Performenceverbesserung habe ich jetzt den Anfang der Zeichenprocedure darauf zurechtgestutzt:Kann man eigentlich gluPerspective(...) auch noch irgendwie entfernen?
Eine zweite Variante zur Performance-Verbesserung habe ich jetzt auch eingebaut, in dem ich die nicht sichtbaren Flächen nicht mehr rendern lasse. Ich weiß trotzdem nicht warum das Programm unter meinem alten Rechner nicht mehr läuft (habe ich vielleicht irgendein Befehl drinnen der unter WIN 95 nicht läuft?).

Zum Thread: wie du vielleicht siehst hat mein Programm bereits einen Thread und da muss ich auch nichts synchronisieren (liegt vielleicht daran, dass ich die Variablen nur vom Formular, aus ausprobiere), läuft aber trotzdem ohne irgendwelchen Fehlern.