Da werd ich mich spätestens ab dem nächsten Update drum kümmern,aber hab bis vor kurzem nicht mal gewusst das es den Header auch in unserer DL-Sektion gibt (sowas nennt man auf Deutsch Organisation )


Gut zu wissen!Wenn sich das als Fehlerquelle bestätigen sollten,dann werd ich den Header vor jedem Update einmal durch Notepad durchjagen,damit sowas nicht mehr passiert.

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

?!? Witzige Geschichte. der Bug liegt nicht in der PAS-Datei, sondern an UltraEdit. Hab' die Datei mit UltraEdit geöffnet um mir den Header mal anzuschaun. Der macht das Problem. Hab' aufgrund eurer Aussage nun den Header in Delphi geöffnet und keinerlei Probleme mehr. Komisch... Dann iss auf jeden Fall alles in Ordnung!

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

Ich will die Unit ja net schlecht machen, aber die apis von den Tutorials
(zumindest die zweite) brechen mit einer Fehlermeldung ab, sobald die
Procedure glKillWnd verarbeitet wird.
Fehlermeldung:

Exception EAccesViolation in module dgl1.exe at 00000000.
Acces violation at address 00000000. Read of Adress 00000000.

Anmerkung: Verwende die zweite API und bin im Tutorial mit den Texturen.
Wenn ich die "normale" OpenGL.pas benutz, tritt der Fehler nicht auf.
Muss also irgendwas mit der dglopengl.pas zu tun haben.

_________________
I'm not the signature, I'm just cleaning the floor...

Derzeitiges Projekt:
FireBlade Particle Engine (Release R2 2009.06.29)

Die Unit wurde auch Anlehnung an Mike Lischkes OpenGL12.pas entwickelt, und benötigt dann beim Umstieg von der normalen OpenGL.pas evtl. ein paar Änderungen.So sollte man z.B. nicht mehr mit wglMakeCurrent arbeiten, sondern stattdessen ActivateRenderingContext und DeActivateRenderingContext verwenden, wie das auch bei Mike Lischkes Unit der Fall ist.
Wie gesagt wurde halt wert auf eine einfache Transition von der OpenGL12.pas auf unsere Unit gelegt und nich von der normalen OpenGL.pas.Da ists halt klar das man da was anpassen muss.
Und da die Templates auch schon recht alt sind,ists logische Konsequenz das die mit der neuen Unit Probleme machen...es liegt also definitiv nicht an der dglOpenGL.pas,allerdings sollte man schon wissen wie man die neue Unit verwendet.

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

Danke!

Aber eine Frage noch:
Warum kann ich ActivateRenderingContext nicht mehr in Ifschleifen verwenden ?!

_________________
I'm not the signature, I'm just cleaning the floor...

Derzeitiges Projekt:
FireBlade Particle Engine (Release R2 2009.06.29)

Beschreib dein Szenario mal bitte genauer.Denn normalerweise ruft man ActivateRenderingContext nur einmal auf,nämlich nachdem du deinen Renderkontext erstellt hast und dann beim Beenden des Programmes auch nur einmal DeActivateRenderingContext.

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

Also:

Hab in der API die beiden wglMakeCurrent durch ActivateRenderingContext ersetzt. (Hoffe das war richtig... bin absolut neu auf OpenGL gebiet
und jetz meckert er:
Operator not applicable to this operand type!

Und hier nochmal eine der veränderten Schleifen:

if (not ActivateRenderingContext(h_DC, 0)) then
MessageBox(0, 'Release of DC and RC failed!', 'Error', MB_OK or MB_ICONERROR);

edit: Steht der Befehl net in ner Ifschleife dann gehts

_________________
I'm not the signature, I'm just cleaning the floor...

Derzeitiges Projekt:
FireBlade Particle Engine (Release R2 2009.06.29)

ActivateRenderingContext ist ja auch ne Prozedur (Delphi-Grundlagen!) und gibt von daher keinen Wert zurück mit dem du eine If-Abfrage machen kannst.Wenn du den Renderkontext freibgeben willst,dann musst du in dein glKillWindow halt folgendes schreiben :

Dann werden sowohl Renderkontext als auch Gerätekontext ordnungsgemäß befreit.Eine Abfrage wie sie im Template ist,braucht man eigentlich nicht.

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

OK, danke vielmals!

_________________
I'm not the signature, I'm just cleaning the floor...

Derzeitiges Projekt:
FireBlade Particle Engine (Release R2 2009.06.29)

In dem Header gibt es noch immer einen Fehler. Soweit ich das gesehen habe auch noch in der Version vom 11.10. Und zwar in der Procedure ReadImplementationProperties;
Dort wird die Funktion wglGetExtensionsStringARB mit GetProcAddress() geladen. Das ganze muss aber mit wglGetProcAddress() erfolgen. Ansonsten wird immer nil zurückgegeben (jedenfalls bei meinem Treiber und so ist es auch auf delphi3d.net beschrieben). Hatte mich schon gewundert, warum meine Grafikkarte die Extensions nicht unterstützen sollte, obwohls überall stand sie könne es.

_________________
Thunderman
Bei schwierigen Problemen entscheiden wir uns einfach für die richtige Lösung. Klar?

Komisch...hab den Header mit nem PBuffer-Beispiel aus meiner Codesammlung getestet und dort hats einwandfrei funktioniert.
Aber trotzdem danke für diesen Hinweis.Werd der Sache nachgehen und dann ggf. ne aktualisierte Headerversion hochladen.

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

es kommt sehr stark auf den treiber an, der im System hinterlegt ist. So exportiert die OpenGL32.dll von nVidia (Win XP) sehr viele wgl-Prozeduren auch direkt. Wenn ein anderer Treiber das nicht tut, gibt's die Funktionen auch nicht per GetProcAdress. Da muss mann dan schon mit wglGetProcAdress arbeiten.

Stellt sich nur die Frage: ist irgendwo (einheitlich) definiert, welche Funktionen mit GetProcAdress und welche mit wglGetProcAdress geladen werden müssen? Denn z.B. bei wglChoosePixelFormat wäre es doch taktishc klüger diese Funktion direkt zu holen, ohne einen temporäre RC erstellen zu müssen...

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

In meinem OpenGL Treiber, der inzwischen auf sehr vielen höchst unterschiedlichen Grafikkarten läuft löse ich das Problem, indem ich sämtliche Routinen auf folgenden Weise importiere:



wglGetProcAddress sollte vor dem ersten Aufruf von glProcedure ganz normal mit

GetProcAddress(GLHandle, 'wglGetProcAddress');

initialisiert werden. Danach holt sich glProcedure selbständig die am besten geeigneten Routinen (wglGetProcAddress könnte nämlich für unterschiedliche Pixelformate die am Besten geeigneten Einsprungpunkte zurückliefern, sodass im Zweifelsfall wglGetProcAddress immer der Vorzug zu geben ist, während GetProcAddress im schlimmsten Fall nur für die Microsoft Standard OpenGL Implementation funktioniert).

Wie auch immer - wenn entwas nicht ganz schief läuft, sollte obiger Code immer den korrekten Funktionszeiger zurückliefern.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Thx für den kleinen Codeschnippsel da oben.Hast du was dagegen wenn ich den in unserem offiziellen Header verwende?Wenn nicht,werd ich den nämlich dahingehend anpassen.

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

Nö, natürlich habe ich nichts dagegen - viel Spaß damit .

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/