PDA

View Full Version : OpenGL command crashing under Lazarus but not Dephi 5



paul_nicholls
06-10-2006, 02:40 AM
Hi all, I use the ScreenToWorld method (below) like so:

Method using code

Begin
{...}
p0 := ScreenToWorld(FMousePosX,FMousePosY,0);
p1 := ScreenToWorld(FMousePosX,FMousePosY,1);
{...}
End;

Method being used

Function TAbaloneGL.ScreenToWorld(AScreenX, AScreenY, AScreenZ : GLdouble) : TVector3f;
Var
Viewport : TViewPortArray;
MVMat : T16dArray;
PJMat : T16dArray;
ObjX : GLdouble;
ObjY : GLdouble;
ObjZ : GLdouble;
Begin
// Retrieves the viewport
glGetIntegerv(GL_VIEWPORT, @Viewport);
// Retrieve the matrices
glGetDoublev(GL_MODELVIEW_MATRIX, @MVMat[0]);
glGetDoublev(GL_PROJECTION_MATRIX, @PJMat[0]);

// Unproject screen coordinates
gluUnProject(
AScreenX,
Viewport[3] - AScreenY,
AScreenZ,
MVMat, PJMat, Viewport,
@ObjX, @ObjY, @ObjZ);

Result := V3(ObjX, ObjY, ObjZ);
End;


This works just find under Delphi 5 without any issues, but when I compile and run it using Lazarus (latest version 0.9.18), it crashes on the gluUnProject line with an access violation :(

If I run it through the debugger it gives this error:

"Project raised exception class 'External: SIGSEGV"

I can't seem to figure it out...

PS I am using the GL.pas and GLU.pas files that come with JEDI-SDL if that helps...

cheers,
Paul.

grudzio
06-10-2006, 10:42 AM
This is strange. I have function like Yours and it runs ok. The only difference is that I have


glGetDoublev(GL_MODELVIEW_MATRIX, @MVMat);
glGetDoublev(GL_PROJECTION_MATRIX, @PJMat);


instead of


glGetDoublev(GL_MODELVIEW_MATRIX, @MVMat[0]);
glGetDoublev(GL_PROJECTION_MATRIX, @PJMat[0]);


But I don't know if this is the problem. If you were compiling on Linux, I would say that probably glu library is not loaded.

Nitrogen
06-10-2006, 05:07 PM
It's probably nothing to do with the actual OpenGL calls being made, but rather, with the link between Delphi/Lazerus and the opengl32.dll file.

Normally these access violations also occur when you forget to bind the opengl functions in delphi with their external addresses in the DLL file.

Clootie
07-10-2006, 02:29 PM
This is strange. I have function like Yours and it runs ok. The only difference is that I have


glGetDoublev(GL_MODELVIEW_MATRIX, @MVMat);
glGetDoublev(GL_PROJECTION_MATRIX, @PJMat);


instead of


glGetDoublev(GL_MODELVIEW_MATRIX, @MVMat[0]);
glGetDoublev(GL_PROJECTION_MATRIX, @PJMat[0]);


But I don't know if this is the problem. If you were compiling on Linux, I would say that probably glu library is not loaded.

IIRC there is some difference either in Delphi and FPC or in static and dynamic arrays referenced by @X and @X[0]. It can give either address of first array element or address of dynamic array pointer. So you better verify this issue.

And yes, it should not be related to OpenGL stuff at all, just to compilers.

paul_nicholls
08-10-2006, 10:10 PM
[quote="Nitrogen"]It's probably nothing to do with the actual OpenGL calls being made, but rather, with the ]

I thought maybe that Lazarus/Freepascal wasn't calling the Initialization and Finalization sections of the GL and GLU pas files as breakpoints don't stop the program there.

So I added the

LoadOpenGL( GLLibName );
LoadGLu( GLuLibName );

and

FreeGLu;
FreeOpenGL

calls around running the main program but it still crashes :(

Any ideas?

cheers,
Paul.

paul_nicholls
08-10-2006, 10:12 PM
This is strange. I have function like Yours and it runs ok. The only difference is that I have


glGetDoublev(GL_MODELVIEW_MATRIX, @MVMat);
glGetDoublev(GL_PROJECTION_MATRIX, @PJMat);


instead of


glGetDoublev(GL_MODELVIEW_MATRIX, @MVMat[0]);
glGetDoublev(GL_PROJECTION_MATRIX, @PJMat[0]);


But I don't know if this is the problem. If you were compiling on Linux, I would say that probably glu library is not loaded.

IIRC there is some difference either in Delphi and FPC or in static and dynamic arrays referenced by @X and @X[0]. It can give either address of first array element or address of dynamic array pointer. So you better verify this issue.

And yes, it should not be related to OpenGL stuff at all, just to compilers.

I have tried both versions, with the [0] and without the [0] to no avail :(

cheers,
Paul.

JernejL
08-10-2006, 11:09 PM
what is the content of those variables? perhaps it is NAN or something similar, due to memory corruption, just check it out, ok?

paul_nicholls
08-10-2006, 11:50 PM
what is the content of those variables? perhaps it is NAN or something similar, due to memory corruption, just check it out, ok?


MVmat = {
-1 ,1.86e-008,-1.56e-008,0,
0 ,0.64 ,0.766 ,0,
2.43e-008,0.766 ,-0.642 ,0,
0 ,10 ,-400 ,1}


PJMat = {
1.81,0 ,0 ,0,
0 ,2.41,0 ,0,
0 ,0 ,-1.0,-1,
0 ,0 ,02 ,0
}


I dunno if this helps...

Paul.

paul_nicholls
09-10-2006, 05:19 AM
Hi all,
To try and track down the gluUnproject issue I am having, I have whipped up a minimal SDL Lazarus project that is available for download here (approximately 700Kb):

http://abalonegl.eonclash.com/gluunproject_test.zip

If someone could find the time to download and try the file it would be excellent. This issue is driving me nuts!!

After downloading the zip file, build it in Lazarus (under windows), run it and see if the problem happens.

When run, a SDL window opens up.

Escape will close the program.
Right-click in the window will attempt to call the gluUnproject routine via the ScreenToWorld() function and it should crash...

If someone could help it would be great!

Thanks :)

cheers,
Paul.

JernejL
09-10-2006, 07:40 AM
i can't debug it, it can't find any dlls and they are in same folder with the exe :(

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...

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

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


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}

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

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

to

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

paul_nicholls
09-10-2006, 09:57 PM
All right, I've managed to make it run without crush.
the gluUnProject declaration should be changed from

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

to

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


Thanks everyone!! I have changed the declaration to this


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

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.php/Talk: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:


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


(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


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


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

paul_nicholls
09-10-2006, 10:28 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.php/Talk: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:


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


(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


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


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 :D

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)


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

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:

{**********************************************}
{ 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;

where TbmRay is defined thusly:

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

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.

paul_nicholls
11-10-2006, 02:31 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:

{**********************************************}
{ 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;

where TbmRay is defined thusly:

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

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.

When you say you tested it using the latest FPC compiler, does that include the one under Lazarus 0.9.18?

That is what I am using. I know theoretically it should be the same, but perhaps there are some differences...


(I used just the glunprojecttest.dpr and sdlapplicationunit.pas files)

EDIT: wait a minute, does this mean you used the GLU and GL files that come with FPC and not the ones that I supplied?

It so, then those DON'T have any issues what so ever...

cheers,
Paul.

cragwolf
11-10-2006, 10:22 AM
When you say you tested it using the latest FPC compiler, does that include the one under Lazarus 0.9.18?

I don't know what Lazarus 0.9.18 uses, because I don't use Lazarus.



(I used just the glunprojecttest.dpr and sdlapplicationunit.pas files)

EDIT: wait a minute, does this mean you used the GLU and GL files that come with FPC and not the ones that I supplied?

I tested your demo with the GL and GLU files that come with FPCv2.0.4, and I tested it with the GL and GLU files that come with JEDI-SDLv1.0 (beta). Your GL and GLU units seem to come from JEDI-SDL, although I'm not sure which version of JEDI-SDL.

michalis
11-10-2006, 01:06 PM
From my experience, jedi-sdl was never tested enough with FPC. That's why I assumed that making jedi-sdl GL/GLU units compatible with FPC is a waste of time, since FPC distribution already provides these units too. So I was satisfied with GL/GLU units working under Delphi/Kylix, providing compatible layer to FPC GL/GLU units.

However, I'm glad to know that you want to make jedi-sdl GL/GLU units compatible with FPC. I'll diff GL/GLU jedi-sdl and FPC units and will submit a patch soon with any necessary corrections to jedi-sdl. I will also patch FPC units to include GL 2.0 updates in jedi-sdl glext unit, I wanted to do this since a long time anyway. So FPC and jedi-sdl units will get synched.

cragwolf: I can't explain why you can't reproduce the problem with Windows and compiling with FPC using jedi-sdl glu unit... I would double-check that you're indeed using the jedi-sdl glu, not the one supplied with FPC (as the one supplied with FPC will work, we know this). As for Lazarus 0.9.18: it includes exactly FPC 2.0.4.

grudzio
11-10-2006, 04:10 PM
I just would like to add that it does not matter if modelMatrix, projMatrix and viewport variables of gluUnProject are declared as var or const. But removing even one of those modifiers causes program to crush on win32 (XP). I tested it on FPC 2.0.2 and 2.0.4 with and without Lasarus (0.9.14).

technomage
11-10-2006, 10:44 PM
We have been testing under FPC for about 4 years now . I do all the linux tests under Free Pascal as I don't have Kylix. What we need are more examples with which to test stuff (or a comprehensive set of unit tests, but who has the time for that :wink:).

As for the GL/GLU changes, bear in mind that we get our headers from http://www.delphi3d.net then make them sdl compatable. the last merge was a few months ago to allow us to support the OpenGL 2.0 API (specifially GLSL). which was tested under both Delphi and FPC on Windows and Linux. I don't think the FPC units are as uptodate as that (please correct me if I am wrong), mind you the GL and GLU units haven't changed much in years so it shouldn't be too much of a problem.

Once you have made your changes let me know and I will test them under windows and linux.

paul_nicholls
12-10-2006, 12:19 AM
From my experience, jedi-sdl was never tested enough with FPC. That's why I assumed that making jedi-sdl GL/GLU units compatible with FPC is a waste of time, since FPC distribution already provides these units too. So I was satisfied with GL/GLU units working under Delphi/Kylix, providing compatible layer to FPC GL/GLU units.

However, I'm glad to know that you want to make jedi-sdl GL/GLU units compatible with FPC. I'll diff GL/GLU jedi-sdl and FPC units and will submit a patch soon with any necessary corrections to jedi-sdl. I will also patch FPC units to include GL 2.0 updates in jedi-sdl glext unit, I wanted to do this since a long time anyway. So FPC and jedi-sdl units will get synched.

cragwolf: I can't explain why you can't reproduce the problem with Windows and compiling with FPC using jedi-sdl glu unit... I would double-check that you're indeed using the jedi-sdl glu, not the one supplied with FPC (as the one supplied with FPC will work, we know this). As for Lazarus 0.9.18: it includes exactly FPC 2.0.4.

I did notice that I still need to use the glext file that comes with JEDI-SDL as the FPC version doesn't have various ARB routines that I require for my shader classes...

Identifier not found "GL_FRAGMENT_SHADER_ARB"
Identifier not found "GL_OBJECT_COMPILE_STATUS_ARB"
Identifier not found "GL_OBJECT_INFO_LOG_LENGTH_ARB"
Identifier not found "GL_OBJECT_]http://abalonegl.eonclash.com/gluunproject_test.zip[/url]

cheers,
Paul.

michalis
12-10-2006, 01:34 AM
Done. The patch to make jedi-sdl GLU unit work with FPC is submitted to sf tracker, see http://sourceforge.net/tracker/index.php?func=detail&aid=1575635&group_id=43805&atid=437446. The patch to make FPC glext unit include all latest OpenGL 2.0 extensions was just sent to the fpc-devel mailing list.

Paul: for now you can just take GLU unit from FPC, and take glext unit from jedi-sdl sources. This will make your program bug-free and all needed OpenGL features will be available. Alternatively, you can wait until the patches will be applied to FPC or jedi-sdl and then use their SVN or CVS versions. Alternatively, you can just apply the patches yourself to your local copy of FPC or jedi-sdl.

paul_nicholls
12-10-2006, 02:46 AM
Done. The patch to make jedi-sdl GLU unit work with FPC is submitted to sf tracker, see http://sourceforge.net/tracker/index.php?func=detail&aid=1575635&group_id=43805&atid=437446. The patch to make FPC glext unit include all latest OpenGL 2.0 extensions was just sent to the fpc-devel mailing list.

Paul: for now you can just take GLU unit from FPC, and take glext unit from jedi-sdl sources. This will make your program bug-free and all needed OpenGL features will be available. Alternatively, you can wait until the patches will be applied to FPC or jedi-sdl and then use their SVN or CVS versions. Alternatively, you can just apply the patches yourself to your local copy of FPC or jedi-sdl.

Thanks michalis for you hard work, and everyone else here :-)

I am currently using the FPC GLU and GL units, and the JEDI-SDL GLEXT unit :)

cheers,
Paul.

cragwolf
12-10-2006, 08:20 AM
I will also patch FPC units to include GL 2.0 updates in jedi-sdl glext unit, I wanted to do this since a long time anyway.

I tried to download your patch for FPC from here (http://lists.freepascal.org/lists/fpc-devel/2006-October/009067.html) but the ]cragwolf: I can't explain why you can't reproduce the problem with Windows and compiling with FPC using jedi-sdl glu unit... [/quote]

I will try it again tomorrow. Probably I am not doing something right.

michalis
13-10-2006, 03:50 AM
I sent the patch to cragwolf, but it's also publicly available now at http://www.freepascal.org/mantis/view.php?id=7600.

paul_nicholls
13-10-2006, 04:00 AM
I sent the patch to cragwolf, but it's also publicly available now at http://www.freepascal.org/mantis/view.php?id=7600.

Pardon me if this is a 'stuipid question (tm)' ;-) but how does one use a .patch file anyway?

cheers,
Paul.

michalis
13-10-2006, 03:19 PM
Pardon me if this is a 'stuipid question (tm)' ;-) but how does one use a .patch file anyway?

Man, I was asked this question way too many times. I guess that you can call this question "my FAQ", so today I decided to put the answer on my webpage: http://www.camelot.homedns.org/~michalis/faq_patch.php. This is somewhat based on my old email on jedi-sdl when Dean "Technomage" asked this question.

savage
25-11-2006, 11:43 PM
Hi Michalis,
I finally got round to apply your patch to glu.pas in CVS and a few other patches that developers had posted. Thanks again for taking the time to post the patch.