TAK Wo ist jetzt genau das Problem? Das verstehe ich gerade nicht? Mag sein, dass ich da auf dem Schlauch stehe.

Bevor ich die neuen Procedurepointer übergebe, sollen alle proceduren auf nil gestellt sein.
Sonnst würde man ja bei funktionen die nicht unterstützt werden aufeinmal OpenGL proceduren aufrufen und das soll ja nicht.
Denn mir ist ne exception lieber als irgendwelcher müll. Da ich den exceptionhandler in Freepascal selber festlegen kann.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Ja das ist auch ein bisschen schwirig. Die methode ClearExtension wird intern nicht verwendet und auch sonst nicht. Und da es für uns einfach mehr arbeit gemacht hat dieses weiter zu pflegen war es besser sie zu entfernen. Abgesehen davon, dass der Header mit seinen 1.3 MB Quellcode eh schon ziemlich häftig ist. Und intern haben wir knapp 4-5 Stellen wo wir eine Methode Eintragen müssen. Sollte diese noch für .NET anders sein so werden das dann mal eben doppelt so viele. Und das ist so schon ein wahnsinniger Aufwand auch ohne etwas was nicht benutzt wird.

Ich kann dein Problem natürlich verstehen aber aus oben genannten Gründen stehen die Chancen, dass wir es einbauen, leider gar nicht so gut. Das in deinem Code selber einzubauen wäre mittels Minnicode oder Regular Expressions (Delphi Suchen & Ersetzen) recht schnell gelöst. Oder hast du schon mal überlegt Mesa als SoftwareRenderer zu benutzen. Der sollte ja eigentlich alles unterstützen und eigentlich sollte der auch gar nicht mal so langsam sein. Ich denke mal die dürften den schon ganz gut optimieren.

Daran dachte ich schon aber erstens ist er nicht optimiert sogar ziemlich langsam und 2. ist mein Renderer für Handheld gedacht.
Ich hab auch kein Mesa auf arm basis gefunden und ausserdem will ich mal ein Softwarerenderer schreiben

Naja dann werde ich halt bei V1.6 bleiben, .Net halte ich eh für ne Krankheit und die 2-3 Extensions die vieleicht interessant werden könnten kann ich mir dann selber in den Header implementieren.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Eigentlich sollte das doch kein Problem sein. Wenn es die Funktion nicht gibt, das liefert wglGetProcAddress doch sowieso nil zurück.

Sehr gute Idee ^^ auf die einfachsten sachen kommt man selber meistens nicht aber wozu gibs ja andere Programmierer.
Ich werde mal die Tage es probieren darüber zu lösen und den neuen Header ein zu binden.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Versionshistory auf Version 2.1 upgedatet.

ich möchte mal auf die Zeitspanne zwischen den letzten Posts (Dem von Lossy und dem von Tak2004) hinweisen

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Was möchtest du mir damit sagen? Habe das erste Post editiert und da man das sonst nicht sehen würde. Aber okay. Ich denke ohne Hinweis fällt das auch keinem Auf.

hey.
ich bin auf diesen header gestoßen, als ich nach einem erweiterten OGL header gesucht habe - in dem stadart header der meiner d7 version beiliegt fehlten nämlich die textur methoden. etwas sauer ist mir dabei das geänderte initialisierungs system aufgestoßen: Das mit InitOpenGL ist ja noch in ordnung aber mit dem rc und dc konnte ich mich zuerst so gar nicht anfreunden.
was mich enorm gestört hat, ist, das es keine funktionen sondern prozeduren sind, was fürs "fehlerlesen" etwas arg unpraktisch ist. ich weis gerne, ob das funktioniert hat, oder nicht. also habe ich mir das dann geändert und wollte hier vorschlagen, das offiziell zu übernehmen.
es geht nicht darum alle prozeduren umzuformen, nur die jenigen, die etwas "aktivieren" und bei denen fehler auftreten können.
ich orientiere mich grob an den nehe tutorials und finde den ansatz zur fehleridentifizierung ganz gut (auch wenn kritische stimme sagen werden : DEBUGGER! - so ist eine anständige fehlerausgabe für ein fertiges projekt pflicht!)

freundliche grüße
grey


//EDIT

war nicht ganz deutlich, aber es geht um die ActivateRenderingContext procedure

Hallo Grey und willkommen im Forum.

Das mit der Initialisierung leigt daran, dass der Header der bei Delphi (egal welche) dabei ist ziemlich alt ist und nur Funktionen benutzt die von der OpenGL32.dll exportiert werden. Entsprechend ist es da möglich alle methoden Statisch einzubinden. In unserem Header geht das aber nicht. Deswegen müssen alle Methoden dynamisch geladen werden. Das macht das Initialisieren etwas anders. Das mit DC und RC ist im übrigen standard so.

Wenn du Änderungsvorschläge am Header hast, dann sind die jederzeit herzlich willkommen. Da möchte ich dich nur bitten mal bitte die veränderten Codestellen hier zu posten. Oder im Zweifel kannst du mir den Header auch als per Mail schicken. Dann lass ich mal mein Difftool drüber laufen. Und dann schauen wir mal weiter. Aber wenn die nicht zu ausgefallen sind (und das scheint nicht der Fall zu sein), dann sehe ich da eher kein Problem.

hey lossy,
ich werd mal bei gelegenheit meine änderungen zusammenstellen. ich bin außerdem dabei das eine oder andere tutorial zu überarbeiten ... das für texturen ist dermaßen wirr und teils unvollständig. (ich mach dafür aber noch nen neuen thread auf)
mfg grey

Sry, hatte ich schon fast vergessen ...

bin mir grade aber etwas konufs - also ich muss nochmal schaun ob meine änderungen so überhaupt sinnvoll sind.
hatte hier zwar schon was gepostet, aber mir ist grade irgendwie aufgegangen das da fehler drin sind - also mach mal deine beta public und ich sag dir bescheid, wenn ichs doch noch grade gebogen bekomme ....
mfg grey

Hallo,

Ich möchte mein Projekt auf OpenGL3 umstellen, finde aber keinen vollständigen Header für Delphi.
Was ist den derzeit beim dglOpenGL Header in Planung, Stichwort "none deprecate mode".

dglOpenGL.pas unterstützt bereits OpenGL 3.0