Im Voraus: ich weiss dass das jetzt nach ganz schön viel Code aussieht aber ich hab wirklich schon alles probiert und es will GARNICHTS tun - ich weiss was es für Arbeit macht, fremden Code durchzugehn und entschuldige mich hiermit förmlichst, dass ich es wage, euch das anzutun

Ich schätze mal das Thema wurde hier schon 100mal gestellt, da es aber in 90% der Fälle ein anderer Fehler ist wird mir hier die Suchfunktion wohl nix nutzen ^^

Wenn ich mein Panel initialisiere und dann zeichne passiert nämlich GAR NICHTS - und nachdem ich jetzt den ganzen tag mit rumexperimentieren verbracht habe denke ich mal es is einer der Fehler die man als laie nicht findet, die ihr aber hoffentlich sofort seht

ich poste hier jetzt mal grosse teile des programmes aber schön unterteilt, damit jeder da jagen kann wo er seiner Erfahrung nach am meisten findet

ich habe das ganze als Thread am laufen, der sieht folgendermassen aus (glaube hier mal nicht an Fehler, aber sicher is sicher)




äh ja, und in nem Form.Create starte ich den Thread dann




Initialisiert wird das ganze also in Init - hier eine wunderschöne Code-Schlange, zu grossen Teilen Copy & paste aus dem DGL-SDK 8nachdem ichs mit 3 Tuts abgetippt hatte und nix funzte wars mir zu blöd)



OResize, meine OnResize-Prozedur (wie passend ^^)
achtung, was den Part hier angeht bin ich am unsichersten, vielleicht ist hier ja was


Render-prozedur:


und Term:

Das ist ein Fehler den ich auch schon öfters gemacht habe.

Wo rufst du eigentlich dein SwapBuffers auf???

Noch eine kleine Anmerkung zum Thema Thread. Die Executemethode würde ich ein wenig anders gestalten.
In etwa so.


Das Init und Term muss deswegen noch mit in den try except block, da dort ja auch exceptions auftreten können. Und außerhalb von Delphi würde Windows deine komplette Anwendung abschießen. Das wglMakecurrent kannst du dir sparen, da der aktive Renderkontext an dem Thread gekoppelt wird.

Mir ist auch was aufgefallen, das wglMakeCurrent, sollte man nicht jedes mal aktivieren und deaktivieren, sondern nur einmal beim OpenGL Initialisieren aktivieren, und bei OnResize aktivieren.
Ansonsten erst deaktivieren wenns deaktiviert werden muss, zweiter renderkontext oder so.

Das zieh erheblich an der performance sofern man das nicht beachtet.

Was mri noch auffällt, wo setzt du deine Standard OpenGL Befehle beim Initialisieren ?
glClearColor(), glClear(); usw. ?

Eventuell kannst du das Zeichnen ins OnIdle Event verlegen und dann auf den Thread verzichten. Dann wird auch ständig neu gezeichnet und man kann trotzdem noch die restliche Anwendunge bedienen, aber man geht den Schwierigkeiten bei Threads aus dem Weg.

okay, danke schonmal für die mühe die ihr euch gemacht habt



Tja, was SwapBuffers angeht, stand es 2:1 - in den Tutorials von Phoebus und Hanns Tappeiner wurde es mit keinem sterbenswörtchen erwähnt (bin ich mir zumindest ziemlich sicher), in dem von Mr_T wird es erwähnt - da Mr_T aber in der Minderheit war hab ichs weggelassen ^^

Das wglMakeCurrent werd ich wohl drinlassen müssen, da ich mir den Aufwand mit den Threads aus genau dem Grund gemacht habe, dass ich in der fertigen Software wohl 4 solcher panels haben werde


glClear: siehe Render-Prozedur
glClearColor: uuups, das hab ich in Phoebus' Tutorial glatt übersehen



OnIdle: das wird nur ausgelöst, wenn sich die Maus bewegt oder sonstwas (schon getestet), kommt deshalb weniger in Frage... und es würde wohl Verwirrung wegen mehrer Panels geben

Anhang: tatsächlich, auch in Phoebus' Tut war SwapBuffers - nur halt leider wieder in der API drinne

Anhang2: hab jetzt nochmal Phoebus' API-Code durchwühlt und nochmals ein paar befehle gefunden, mit denen tuts es jetzt

Ich denke kaum, dass ich da etwas mit VCL vermische, da ich VCl gar nicht verwende
Aber ist Dir schon aufgefallen, dass wir bei unseren Download komplett lauffähige Templates für API, VCL, SDL, mehre Kontexte etc haben?

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."

äh ich meinte mit API *ggg*

(man bist du schnell ^^)

naja, die benutzen dann aber schon wieder andere units als die openGL von Delphi, von denen ich dann schon nicht mehr wusste ob das jetzt einfach nur neuere Versionen davon sind oder völlig neue Komponenten ect. - und vor denen warnst du ja selber

Das ist wahr. Einige unserer alten Beispiele verwenden die OpenGL1.2-Header von Lischke. Inzwischen bieten wir eigene Header an, die voll kompatibel sein sollte zu den "alten". In jedem Fall sei Dir drigend davon abgeraten die alten Borland-Header einzusetzen. Nimm am besten gleich die DGL-Header, damit solltest Du am wenigsten sorgen haben und es gibt auch gleich ne guten Support
@schnell: nur die ersten zwei Mal, danach dauerts dann ne Ewigkeit

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."

d.h. die dglOpenGL statt der OpenGL nutzen?? (*ist verwirrt weil die irgendwie ... unvollständig ... ist - glTranslate ect.???*)

Nein, die ist gerade nicht unvollständig, sondern die von Borland sind schlichtweg falsch
Schau mal einen Blick ins Wiki: http://wiki.delphigl.com/index.php/GlTranslate
dort siehst Du dann auch, dass der korrekte Funktionsname nach den Manpages "gltranslatef" ist. Borland hat das "f" einfach unterschlagen. Spätestens bei Texturen wirst Du dann feststellen, dass Du funktionen nachimplementieren musst, weil diese erst gar nicht in den Headern drinne sind oder das an einzigen Stellen Pointer erwartet werden, wo sie gar nicht hin sollen.
Zu der Thematik auch bitte den FAQ-Eintrag beachten und das Kommenatar in den Headern ansehen
http://www.delphigl.com/forum/viewtopic.php?t=336

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."

so, jetzt hab ich statt dem von Borland mal eure genommen aber das ergebnis überzeugt nicht so ganz - system crasht, anwendung lässt sich nur mit grossen mühen per taskmanager abschiessen (1 Mausklick hat ne Reaktionszeit von 30 sec)

Ansonsten is der Code 100% der selbe... - mir OpenGL statt dglOpenGL funktionierts problemlos

Ich hoffe du hast dir die mitkommende Readme durchgelesen, da steht drin was man beachten muss... (scheint so als würde da keiner reinschauen)

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

naja, man installiert die SDK, klickt auf tutorials und hofft dann das alles was da drin steht so auch funktioniert

Dann schätze ich auch mal, dass du direkt nach dem Start deiner Anwendung auch kein InitOpenGL aufrufst, oder? Wenn dem so ist, dann sind deine Funktionspointer nämlich nicht initialisiert, und der erste Zugriff auf eine GL-Funktion endet mit einem Absturz.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)