Okay. Habs eingefügt.

Die Variablen modelview,projection und viewport werden in deinem Programm anscheinend direkt auf den Stack gelegt und nicht ein Zeiger auf diese Variablen. gluUnproject benötigt aber den Zeiger. Das ist der Fehler. Daher dann
function gluUnProject(winx, winy, winz: GLdouble;
modelMatrix: PGLdouble;
projMatrix: PGLdouble;
viewport: PGLint;
objx, objy, objz: PGLdouble): Integer; stdcall;
benutzen und
gluUnProject(X, Y_new, Z,@modelview, @projection, @viewport, @Result[0], @Result[1], @Result[2]);

Sowas in der Art hatte ich mir schon gedacht, weil es ja eigentlich immer eine Zugriffsverletzung war.
Aber in der dglOpengl.pas sind die Variablentypen der Parameter vom Typ TGLMatrixd4 weshalb meine Versuche Pointer zu übergeben logischerweise mit dem Compilerfehler

enden. Ist es einfach nur in der dglOpengl falsch definiert oder rafft FPC es nicht? Oder raff ich es nicht?

Ja das ist dann wohl falsch. Da muß entweder der Zeiger oder var hin. "Const" würde zumindest bei Delphi auch funktionieren.

Anscheinend ist var und Pointer für manche Compiler doch nicht das selbe. Das könnte jetzt ein guter Grund sein die alte Variante zumindest parallel zu unterstützen, wenn es noch Resantiments dagegen gibt, es komplett zu ändern.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

In der Datei steht ja weder das eine noch das andere.

dglOpengl.pas 2.0 vom 06.12.2005
Zeile 6233: TgluUnProject = function(winx, winy, winz: TGLdouble; modelMatrix: TGLMatrixd4; projMatrix: TGLMatrixd4; viewport: TVector4i; var objx, objy, objz: TGLdouble): TGLint; {$IFNDEF CLR}{$IFDEF Win32}stdcall; {$ELSE}cdecl; {$ENDIF}{$ENDIF}

Ist das vlt. die falsche Version von dglOpengl?

Ne das ist die aktuelle. Aber da ist wie gesagt in der Deklaration ein Fehler:
Das muß TgluUnProject = function(winx, winy, winz: TGLdouble; modelMatrix: PGLMatrixd4; projMatrix: PGLMatrixd4; viewport: PVector4i; var objx, objy, objz: TGLdouble): TGLint;
heißen und wird in der nächsten Version korrigiert.

Okay. Danke. Reicht es aus, wenn ich die eine Zeile ändere?

Die Frage hat sich grade beantwortet. Ich habe die gluUnproject geändert und die beiden Pointertypen für Matrix und Vektor hinzugefügt. Jetzt liefert das Programm einigermaßen brauchbare Ergebnisse und vor allem: Es stürzt nicht mehr ab.

Danke für eure Hilfe

Weist du was mich derzeit am meisten irritiert? Anscheinend kracht es nur bei dir. Nicht, dass ich es schlimm finde wenn man Fehler entdeckt aber dabei bin ich ein bisschen arg irritiert. Ich habe gerade mal im Wiki und in der Version 1.5 des Headers nachgesehen. Alle machen es so wie es im 2.0er ist. Und der 1.5er Header wurde eine Zeit lang benutzt, da der 1.8er wegen .net bei glu(Un)Project nicht funktionierte. Aber nicht an deinen Problemparametern. Das ganze lässt nur den Schluss zu, dass Delphi so frei ist und automatisch bei solchen Typen einen Pointer auf den Stack packt. Sonst hätten ja die Anwendungen mit dem 1.5er nicht funktioniert. Was sie aber offensichtlich getan haben sonst wäre uns jemand aufs Dach gestiegen.

Ich habe mal im Debugger nachgesehen und Delphi macht das tatsächlich so. Vermutlich liegt dass am stdcall. Da müßte man mal nachlesen wie das die offiziellen Regeln sind, dass ist ja durch Windows vorgegeben.
Dann ist es eventuell doch kein Fehler im Header sondern von FreePascal.

Die Sache mit den Pointern kommt ja von C. Da kann man meines wissens gar keine Arrays übern Stack übergeben. Wenn man da ein Array in der Parameterliste hat, wirds automatisch als Pointer gehandhabt. Kann also tatsächlich sein, dass die bei Borland das bei stdcall so an C angepasst haben.

_________________
[18:30] tomok: so wie ich das sehe : alles. was nich was anderes ist als nen Essay ist nen Essay

hi, i'm a signature viruz, plz set me as your signature and help me spread

http://msdn.microsoft.com/library/defau ... tdcall.asp

Da steht:



Und Arrays sind unter C ja eigentlich immer Referenz Typen.

Wenn man da records statt Arrays in der Funktion nimmt, dann übergibt auch Delphi den Parameter als Wert und nicht als Zeiger,

Wie gesagt: Delphi hab ich nicht zur Hand und konnte es deshalb auch nicht nachkontrollieren. Und es war mir schon fast klar, dass es dadran liegt, dass Freepascal irgendwas falsch macht. Obwohl es ja im Prinzip kein Fehler ist, weil es sich genau an die vorgegebene Definition in der dglOpengl gehalten hat. Und da scheint auch der Delphimode von fpc nix dran zu ändern.
Aber jetzt funzt es ja.