Re: [Nel] Issue to run snowballs2

[Lionel Berenguier]

Okay, sorry for late answer but this an issue I have not yet fixed, and I
apologize, but I still don't know how to (the fact is that here at nevrax we
develop under windows, still trying to support linux, except network guys
which really tests both versions).

David, you're right, glSetFenceNV, glBinProgramNV etc.... are part of NVidia
OpenGL extension, but they are dynamically checked (like all other
extensions) in driver_opengl_extension.cpp.

The difference with other extensions is that they are too recent and don't
exist in GLext.h, so they are defined
in   "driver_opengl_extension_def.h".

I tried to follow same syntax as in GLext.h to define thoses extensions (use
of GL_GLEXT_PROTOTYPES, use of APIENTRY) but it seems that it works under
windows (even with drviers/cards that don't support thoses extensions) but
not under linux. I'm not very aware of dynamci libs (.so) under linux but I
think the problem is that all thoses functions are not "export"-ed and so
the dynamic library loader think the function is in libnel_drv_opengl.so.
And of course it is not.

The test in driver_open_extension.cpp:333  ensure that code that use
glSetFenceNV won't be executed, but it's still compiled and linked.
Therefore it crahses when the libnel_drv_opengl.so  is loaded.

If someone could explains me where I am wrong in
driver_opengl_extension_def.h, it would be cool.

Also, can anybody explains me why under linux/unix we don't have to
dynamically import functions (ie with such call like wglGetProcAdress(), or
window's GetProcAdress()) ??? In other terms, What system underlie the
dynamic library loader (I suppose there is system which fill a table of jump
or something like this but I don't really knows).


thanks

Lionel, Nevrax.

----- Original Message -----
From: "David Mentre" <address@hidden>
To: <address@hidden>
Sent: Tuesday, January 08, 2002 9:39 PM
Subject: Re: [Nel] Issue to run snowballs2


> David Mentre <address@hidden> writes:
>
> > Are those symbols standard OpenGL or Windows specific?
>
> After further investigation, I would say that those symbols (and thus
> library functions) are NVidia specific:
>
> http://oss.sgi.com/projects/ogl-sample/registry/NV/fence.txt
>
> As far as I have understood, the NeL library should have queried the
> OpenGL library to find if those extensions are available and if not use
> a workaround. Am I right?
>
> However, there is some code to test those functions availability:
> driver_opengl_extension.cpp:333:
> if( strstr(glext, "GL_NV_fence")==NULL )
> return false;
>
> Maybe some cleanup would be needed in driver_opengl_extension_def.h?
>
> I would so much play with snowballs! :)
>
> I hope it helps in some way,
> Best regards,
> d.
> --
>  address@hidden
> _______________________________________________
> Nel mailing list
> address@hidden
> http://www.nevrax.org/mailman/listinfo.cgi/nel
>