I try to use GLUT with Kylix everything is fine but… When I to include in my main loop procedure :
procedure Render(); cdecl;
begin
glClear(GL_COLOR_BUFFER_BIT or GL_DEPTH_BUFFER_BIT);
glLoadIdentity();
----=>> glutSolidCone(10,10,10,10);
----=>> glutSolidSphere(10,10,10);
glFlush();
glutSwapBuffers();
end;
My program end automatically with no error prompt, nothing!? If I copy and paste these two line and compile it in C/C++ no problem… Is it a bug in the library translation or I do something wrong!?
No this is the weird thing, I produce the SAME structure in C and i can see my cone or my sphere it’s ONLY on kylix… I don’t get it… And if I replace the two line by ANY other basic object (teapot, cube etc…) no problem, it’s ONLY the sphere and the cone… It really looks like a bug but I’m not sure
I have some experience with the Borland C/C++ compiler under Windows. The compiler did not mask math errors like other compilers so you had to add code for that. It was just a few lines. Perhaps is it the same with Kylix?
it would be not the first and definitly not the last bug in kylix
you can try your pascal code on fpc (www.freepascal.org), should compile without too much to be changed
or perhaps there is some source for the kylix/glut stuff - just joking
i would be very surprised if this is the solution
pascal is very strict with its types and if your function requests a GLdouble it will raise an error if it doesn’t get one (even kylix will do this )
i still think it is just another kylix bug
but without seeing the source of the glut bindings it is really hard to tell
Don’t know about Kylix but in FreePascal you have to tell the linker which libs to link to.
If you don’t do you get the same error you got.
So perhaps in Kylix you have to do this, too.
Just a guess.
p.s.:I think you did take a look if glut.so is actually there
[This message has been edited by satan (edited 07-04-2002).]