Hallo!

Ich bin 3dfx-Freak und programmiere nebenbei auch ganz gerne in Opengl und Delphi.
Der Hauptteil meines Systems ist eine Voodoo 5.
Bisher habe ich es so gemacht, dass ich die Borland opengl.pas verwende und dann den wickedgl dazukopiere. das funktioniert einwandfrei. jetzt wollte ich allerdings wegen der bugs in der Borland-Datei auf die dglOpenGL.pas wechseln.... allerdings schaffe ich es dabei nicht einmal, die 3d-api zu initialisieren. es kommen lediglich irgendwelche exception errors in adresse....
immerhin konnte ich das problem ungefähr isolieren:

Es tritt in dem gdlHeader in dieser Zeile auf (procedure CreateRenderingContext ):

Result := wglCreateLayerContext(DC, Layer);

das result ist = 0, und er bricht ab

ich verstehe allerdings nicht, wieso es mit den borland-headern geht...

und bitte erzählt mir nichts von wegen "veralteter technik" oder "kauf die eine neue grafikkarte". ich will lediglich mein spiel so kompatibel wie möglich machen.

danke schonmal

gruß,
[3dfx] IceFire

Ich weiss jetzt nicht wie im alten Header ein Renderkontext erstellt wurde. Es klingt aber einfach danach, dass der WGL-Befehl nicht im Umfang des Treibers enthalten ist.
Schau einfach mal ob die Funktion nach InitOpenGL <> nil ist.

_________________
Steppity,✲steppity,✴step,❆step,✳step!
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❅ ☃ ❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ☃ ❄ ❆ ❄ ❄

Ich geb es ehrlich zu, ich habe keine Ahnung von Glide, 3dfx, Voodoo oder Mesa3D und hab auch keine Ahnung, warum Borlands opengl.pas funktioniert.
Aber ich habe erst neulich etwas Interessantes zu dem erstengenannten Kram gefunden; und wenn ich das richtig interpretiere, müsste man für Glide die wgl-Funktionen eigentlich emulieren?

MfG

Ersetz wglCreateLayerContext mal mit wglCreateContext und probier obs damit geht. Eigentlich ist das wglCreateLayerContext im Header recht unnötig, Contexte mit Layern werden eh kaum von irgendwelcher Hardware unterstützt.
Sollte auch dass nicht klappen, kannst du dir mit der Windowsfunktion GetLastError nach dem Aufruf von wglCreateContext genauere Informationen zum Fehler holen.

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

wglCreateContext() ist auf jeden fall in der wickedgl implementiert... habs probiert zu ändern. ohne erfolg - der fehler bleibt...
wickedgl ist eine opengl32.dll, die die opengl-befehle für glide übersetzt.
ich hab hier mal n bissl quelltext:

Das ist der teil, der mit den borland headern geht:



wenn ich diese zeilen allerdings ersetze durch diese hier und den header ändere, geht nix mehr :

€dit:
bleibt zu erwähnen, dass die lange initialisierungsmethode mit der dglopengl.dll auch nicht funktioniert....

€dit2:
http://www.koders.com/c/fidEE6E358DE8D4 ... AF440.aspx ist aber wirklich interessant ^^ danke für den link!


Edit Lossy: Pascaltags hinzugefügt

Na ja de einzige wirkliche Unterschied zwischen den beiden Codes ist das Flag PFD_SUPPORT_OPENGL.

Würde es denn gehen, wenn du die manuelle Erstellung des Kontextes der Methode CreateRenderingContext vorziehst? Also in etwa folgendes.


Da ist zwar eigentlich kein wirklicher Unterschied aber du musst nicht zwingend den Kontext mit der dglOpenGL.pas erstellen lassen.

PS: Zu denen von dir im ersten Post genannten Zugriffsverletzungen. An welcher Stelle treten die denn genau auf?

mh, das problem hängt nicht mit der initialisierungsart zusammen, es geht ja leider mit beiden nicht, wie ich heute morgen herausgefunden hab...

demnach hat das problem nichts mit dem source code ansich zu tun... das problem scheint demnach irgendwie im header verankert zu sein...
ist der header definitiv opengl 1.1 kompatibel? die voodoo 5 bietet zwar glaubich bis 1.4, bin mir da allerdings nicht sicher.

das auftreten des fehlers kann ich leider nicht zurückverfolgen... es kommt einfach zugriffsverletztung an adresse 00000000.
merkwürdig...

Die Frage die sich mir da stellt ist die ob 3dfx einen echten OpenGL Treiber im System installiert? Bzw laufen auch andere echte opengl programme?

Denn normal installiert ein Treiber eine DLL und registriert diese im System. Die OpenGL32.dll spricht diese dann an und leitet alle Aufrufe weiter. Und unser Header sprich ohne weiteres Zutun nur die OpenGL32.dll an.

Ich vermute mal, dass da irgendwo etwas schief gegangen ist. Denn die OpenGL32.dll sollte eigentlich OpenGL 1.1 per Software anbieten sofern nichts installiert wurde. Und das funktierte bisher immer recht gut. Selbst unter 98 in einer virtuellen Maschine.


Ich kenne mich leider mit 3dfx auch nicht aus. Das liegt vor meiner Zeit. Habe zwar noch eine Voodoo 1 irgendwo rumliegen aber na ja. Von daher kann ich dir so auch nur bedingt helfen. Du solltest mal mit dem Debugger Stück für Stück durch dein Programm steppen und schauen welche Methode nicht geladen werden konnte. Ich könnte mir auch gut vorstellen, dass das OpenGL bei 3dfx eher aus einer anderen DLL kommt.

Was mich daran allerdings etwas sehr irritiert ist die Sache, dass es mit der ollen OpenGL.pas keine Probleme gab. Und bis auf, dass wir die DLL dynamisch laden gibt es dort keinen Unterschied und das sollte eigentlich auch kein Unterschied machen.

ich benutze als opengl-treiber der voodoo den wickedgl, der opengl praktisch emuliert und an das glide-interface weiterleitet.
mh, keine ahnung. ich werde wohl noch einige zeit daran zu knabbern haben...

Unterstützt die Voodoo 5 eigentlich 32 Bit Farbtiefe ? Also 24 RGB + 8 Alpha bits ?

Liegt es eventuell daran, das der DGLOpenGL Header die Alphabits standardmässig benutzt ?
Vielleicht kann das die voodoo 5 ja nicht. (hast ja in deinem working source dazu geschrieben das es nicht supported wird)