OpenGL command crashing under Lazarus but not Dephi 5

**savage** · 09-10-2006, 08:55 AM

I don't have FreePascal installed at the moment, but from past experience, OpenGL crashes between compilers is usually caused by one compiler being more strict about the function declarations than another.

in glu.pas, gluUnProject is currently declared as...
[pascal]
gluUnProject: function(winx, winy, winz: GLdouble; const modelMatrix, projMatrix: T16dArray; viewport: TViewPortArray; objx, objy, objz: PGLdouble): Integer; {$IFDEF WIN32}stdcall;{$ELSE}cdecl;{$ENDIF}[/pascal]

which looks fine to me, when compared to the C code. But maybe a declaration of...

[pascal]
gluUnProject: function(winx, winy, winz: GLdouble; const modelMatrix, projMatrix: T16dArray; viewport: TViewPortArray; var objx : GLdouble; var objy : GLdouble; var objz : GLdouble ): Integer; {$IFDEF WIN32}stdcall;{$ELSE}cdecl;{$ENDIF}[/pascal]

would be more cross compiler compatible and possibly more correct.

I tested this change with Delphi 6 ( I need to make some small changes to your demo project ) and it does not crash. Why not give it a try with FPC and let us know.

**grudzio** · 09-10-2006, 01:05 PM

I have downloaded your code and it crushes under Lasarus (0.9.14 + fpc 2.0.2). Changing the glu.pas header as Savage suggested did not help.
I also have compiled program under Linux (FPC 2.0.2) and it works :shock: . So I would say something is wrong with FPC for windows.

Can't help you more I am afraid

**grudzio** · 09-10-2006, 03:31 PM

All right, I've managed to make it run without crush.
the gluUnProject declaration should be changed from
[pascal]
gluUnProject: function(winx, winy, winz: GLdouble; const modelMatrix, projMatrix: T16dArray; viewport: TViewPortArray; objx, objy, objz: PGLdouble): Integer; {$IFDEF WIN32}stdcall;{$ELSE}cdecl;{$ENDIF}
[/pascal]
to
[pascal]
gluUnProject: function(winx, winy, winz: GLdouble; var modelMatrix, projMatrix: T16dArray; var viewport: TViewPortArray; objx, objy, objz : GLdouble ): Integer; {$IFDEF WIN32}stdcall;{$ELSE}cdecl;{$ENDIF}
[/pascal]

**paul_nicholls** · 09-10-2006, 09:57 PM

Originally Posted by grudzio

All right, I've managed to make it run without crush.
the gluUnProject declaration should be changed from
[pascal]
gluUnProject: function(winx, winy, winz: GLdouble; const modelMatrix, projMatrix: T16dArray; viewport: TViewPortArray; objx, objy, objz: PGLdouble): Integer; {$IFDEF WIN32}stdcall;{$ELSE}cdecl;{$ENDIF}
[/pascal]
to
[pascal]
gluUnProject: function(winx, winy, winz: GLdouble; var modelMatrix, projMatrix: T16dArray; var viewport: TViewPortArray; objx, objy, objz : GLdouble ): Integer; {$IFDEF WIN32}stdcall;{$ELSE}cdecl;{$ENDIF}
[/pascal]

Thanks everyone!! I have changed the declaration to this

Code:

gluUnProject&#58; function&#40;winx, winy, winz&#58; GLdouble; var modelMatrix, projMatrix&#58; T16dArray; var viewport&#58; TViewPortArray; objx, objy, objz&#58; PGLdouble&#41;&#58; Integer; &#123;$IFDEF WIN32&#125;stdcall;&#123;$ELSE&#125;cdecl;&#123;$ENDIF&#125;

and it works beautifully in both Delphi 5 and Lazarus!!

Thanks again!

cheers,
Paul.

**michalis** · 09-10-2006, 10:15 PM

The answer is simple: you shouldn't use GL and GLU units from jedi-sdl when compiling under FPC. See the "FPC and SDL" wiki page http://www.freepascal.org/wiki/index.php/FPC_and_SDL and especially my reply in section "unitpath in fpc.cfg" on the discussion page: http://www.freepascal.org/wiki/index...lk:FPC_and_SDL. The problem is described there, and the summary is: GL and GLU from jedi-sdl should be used only for Delphi/Kylix, and with FPC you should use the GL/GLU units provided in it's distribution.

So the proper solution to your problem is just to remove gl.pas and glu.pas from your project directory (and make sure that jedi-sdl OpenGL dir is nowhere on FPC units path). As soon as FPC uses it's own GL/GLU units, the problem is fixed, no segfaults. And FPC OpenGL units are compatible enough to let you write the same code and have it compiled under both FPC and Delphi.

Alternatively, you could put $ifdef FPC and use the following FPC version of gluUnProject in GLU unit:

[pascal]
gluUnProject: function(winx, winy, winz: GLdouble; var modelMatrix, projMatrix: T16dArray; var viewport: TViewPortArray; objx, objy, objz: PGLdouble): Integer;
{$IFDEF WIN32}stdcall;{$ELSE}cdecl;{$ENDIF}
[/pascal]

(I actually pasted the first declaration line from FPC glu sources). But that's bad solution. Like I said: the proper solution is just to let FPC use it's own GL/GLU units.

Note: this is not a bug of FPC, neither a bug of Delphi. All Pascal compilers have some freedom to choose when parameters are passed by value and when by reference --- in this case Delphi was more willing to pass parameters by reference than FPC. GPC has construction to explicitly force constant paremeters being passed by reference, but neither FPC nor Delphi implement them.

Jedi-sdl people: could you add something like

[pascal]
{$ifdef FPC}
{$fatal This unit shouldn't be used with FPC. Instead you should use the FPC own OpenGL units.}
{$endif}
[/pascal]

inside your gl and glu units ? This would avoid these problems.

**paul_nicholls** · 09-10-2006, 10:28 PM

Originally Posted by michalis

The answer is simple: you shouldn't use GL and GLU units from jedi-sdl when compiling under FPC. See the "FPC and SDL" wiki page http://www.freepascal.org/wiki/index.php/FPC_and_SDL and especially my reply in section "unitpath in fpc.cfg" on the discussion page: http://www.freepascal.org/wiki/index...lk:FPC_and_SDL. The problem is described there, and the summary is: GL and GLU from jedi-sdl should be used only for Delphi/Kylix, and with FPC you should use the GL/GLU units provided in it's distribution.

So the proper solution to your problem is just to remove gl.pas and glu.pas from your project directory (and make sure that jedi-sdl OpenGL dir is nowhere on FPC units path). As soon as FPC uses it's own GL/GLU units, the problem is fixed, no segfaults. And FPC OpenGL units are compatible enough to let you write the same code and have it compiled under both FPC and Delphi.

Alternatively, you could put $ifdef FPC and use the following FPC version of gluUnProject in GLU unit:

[pascal]
gluUnProject: function(winx, winy, winz: GLdouble; var modelMatrix, projMatrix: T16dArray; var viewport: TViewPortArray; objx, objy, objz: PGLdouble): Integer;
{$IFDEF WIN32}stdcall;{$ELSE}cdecl;{$ENDIF}
[/pascal]

(I actually pasted the first declaration line from FPC glu sources). But that's bad solution. Like I said: the proper solution is just to let FPC use it's own GL/GLU units.

Note: this is not a bug of FPC, neither a bug of Delphi. All Pascal compilers have some freedom to choose when parameters are passed by value and when by reference --- in this case Delphi was more willing to pass parameters by reference than FPC. GPC has construction to explicitly force constant paremeters being passed by reference, but neither FPC nor Delphi implement them.

Jedi-sdl people: could you add something like

[pascal]
{$ifdef FPC}
{$fatal This unit shouldn't be used with FPC. Instead you should use the FPC own OpenGL units.}
{$endif}
[/pascal]

inside your gl and glu units ? This would avoid these problems.

thanks for all the hints michalis

I will read those posts :-)

cheers,
Paul.

**technomage** · 10-10-2006, 07:01 PM

JEDI-SDL should support FPC as well as Delphi and Kylix (we work hard to make sure this is the case), so I'll suggest we do something special for that particular unit.

Dom, I'll make the IFDEF changes toinclude the var tothe viewport at my end and test it. If it works fine on both fpc under linux and fpc under windows and deplhi we'll include the change in v1.0

**savage** · 10-10-2006, 09:54 PM

I agree with technomage, I think a change should me made to the jedi-sdl gl and glu units so that they work with both Delphi/Kylix and FPC.

Our aim is to be as cross-compiler and cross-platform as possible. So if a change is required withing jedi-sdl just let us know and we will do our best to make it so.

**grudzio** · 11-10-2006, 12:15 AM

On Linux glu.pas works good as it is, at least for me, so I think that problem is not in SDL gl headers but with FPC.

To make things more interesting I found another working version of gluUnProject (WIN32)

[pascal]
gluUnProject: function(winx, winy, winz: GLdouble; const modelMatrix, projMatrix: T16dArray; const viewport: TViewPortArray; objx, objy, objz: PGLdouble): Integer; {$IFDEF WIN32}stdcall;{$ELSE}cdecl;{$ENDIF}
[/pascal]
All three arrays are passed as consts.

And I suppose if the declaration of gluUnproject should be changed, so should gluProject.

**cragwolf** · 11-10-2006, 01:59 AM

I have tested the gluUnProject function from both FPC's and JEDI-SDL's glu unit in both Linux and Windows using the latest FPC compiler, and I have not run into any problems. I use the gluUnProject function in the following way:

[pascal]{**********************************************}
{ Generates a ray based on a window coordinate }
{**********************************************}
function GenerateRay(x, y: Integer): TbmRay;
var
modelmatrix, projmatrix: T16dArray;
viewport: TViewPortArray;
objxn, objyn, objzn, objxf, objyf, objzf: GLDouble;
begin
{ Get the modelview and projection matrices and the viewport data }
glGetDoublev(GL_MODELVIEW_MATRIX, @modelMatrix[0]);
glGetDoublev(GL_PROJECTION_MATRIX, @projMatrix[0]);
glGetIntegerv(GL_VIEWPORT, @viewport[0]);
{ gluUnProject z=0 for the nearplane; z=1 for the far plane }
gluUnProject(x, y, 0, modelMatrix, projMatrix, viewport, @objxn, @objyn, @objzn);
gluUnProject(x, y, 1, modelMatrix, projMatrix, viewport, @objxf, @objyf, @objzf);
{ ray = near + t * (far - near) }
Result.vStart[0] := objxn; Result.vStart[1] := objyn; Result.vStart[2] := objzn;
Result.vDel[0] := objxf - objxn; Result.vDel[1] := objyf - objyn; Result.vDel[2] := objzf - objzn;
end; [/pascal]

where TbmRay is defined thusly:

[pascal]TbmVector = array[0..2] of Double;
TbmRay = record
vStart: TbmVector;
vDel: TbmVector;
end;[/pascal]

Similarly, I have tested Paul's code with the latest FPC compiler (I used just the glunprojecttest.dpr and sdlapplicationunit.pas files) in both Linux and Windows, and again I have run into no problems.

So if there is a bug it is either with Lazarus or some aspect of your system.

Perhaps Michalis can tell us exactly which functions in JEDI-SDL's opengl units are incorrectly declared, so that we can test that and fix them if necessary. This would be a good thing to get right for the 1.0 release.