Re: [Nel] Issue to run snowballs2

[Vincent Caron]

On Tue, 2002-01-22 at 10:04, Lionel Berenguier wrote:
> 
> Thank you Vincent for this great clarification. In your own experience, is
> glXGetProcAddressARB widely supported ???

If you want accelerated 3D support under Linux, you either get the old
Mesa way (3DFX), utah-glx under XFree 3.3.x which is Mesa-based, DRI
under XFree 4.x which is Mesa-based and finaly Nvidia proprietary
drivers. They all support glXGetProcAddressARB to my knowledge. I
checked for Mesa : it appeared on the 3.3 branch on 1999/12/11 (
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mesa3d/Mesa/include/GL/glx.h?rev=1.10&content-type=text/vnd.viewcvs-markup
 - see end of file). Nvidia had it since its early driver releases (0.9-767 of 
2001/02/13).

So I would say, yes, it _is_ supported :)

> If yes, what I have to do is undef GL_EXT_PROTOTYPES, and use same scheme as
> windows, isn't it ??

Yes.

But I just re-read this thread and realized my last mail contained a big
mistake : I was talking about dlopen'ing libGL.so, which you're not
doing. I was actually thinking with the quake model : Carmack dlopen
libGL.so or opengl32.DLL, and then import every symbol one by one. It
had some advantage at the time of mini-GL and QuakeGL, where you had no
means to choose your driver interface at run-time, but loading the right
DLL. And ID has its own GL tracer/debugger which wraps all GL calls
(they code the engine with a 'qgl*' API).

Now, I think you're right and ID is wrong. ID bypass the standard loader
link stage by dlopen'ing libGL.so, while you do the right thing by
linking nel_drv_opengl.so with libGL at compile time, letting the
runtime loader do its job (it will actually load the right libGL.so for
you when you dlopen nel_drv_opengl.so, thus relying on the user/distro
to have a proper GL setup, and not trying to workaround).

The point I wanted to make (finaly, sorry for being so verbose :)), is
that in this case you'll end with two definitions of a GL extension
symbol under Linux :

a) PFNGLSETFENCENVPROC  glSetFenceNV; // =
glXGetProcAddressARB("glSetFenceNV");

b) nm -D /usr/lib/libGL.so|grep glSetFenceNV
0001b368 T glSetFenceNV

The linker will complain (it says 'type of symbol `glSetFenceNV' changed
from 2 to 1', ahem!), but it seems that our redefinition here gets the
precedence over the libGL.so symbol. I'm not very confident with this
link stuff, but I'm eager to learn more, that's why I'm taking some time
to tackle this issue with you.

I tried to test it on nel GL driver directly, but there are some issues
to clean up first :

- ARB_multitexture is not a GL extension since OpenGL 1.2.1. Since you
should expect 1.3 compliant drivers till Ryzom is ready, I guess there
is no need to import these symbols for pre-1.2.1 drivers ? Currently,
the protos from driver_opengl_extension.h conflicts with plain
definitions of my GL/gl.h :

  // in driver_opengl_extension.h :
  extern PFNGLACTIVETEXTUREARBPROC glActiveTextureARB;

  // in GL/gl.h : (not enclosed by #ifdef's)
  GLAPI void GLAPIENTRY glActiveTextureARB(GLenum texture);

- Get rid of some wgl dependencies : replace

  extern PFNWGLALLOCATEMEMORYNVPROC wglAllocateMemoryNV;
  extern PFNWGLFREEMEMORYNVPROC  wglFreeMemoryNV;

with something like :

  #ifdef NL_OS_WINDOWS
  typedef PFNWGLALLOCATEMEMORYNVPROC PFNGLEXTALLOCATEMEMORYNVPROC;
  typedef PFNWGLFREEMEMORYNVPROC PFNGLEXTFREEMEMORYNVPROC;
  #endif
  #ifdef NL_OS_UNIX
  typedef void *(*PFNGLEXTALLOCATEMEMORYNVPROC)(GLsizei, GLfloat,
GLfloat, GLfloat);
  typedef void (*PFNGLEXTFREEMEMORYNVPROC)(GLvoid *);
  #endif
  extern PFNGLEXTALLOCATEMEMORYNVPROC glextAllocateMemoryNV;
  extern PFNGLEXTFREEMEMORYNVPROC glextFreeMemoryNV;

 (and update the code in .cpp to fetch the right function name, "wgl*"
or "glX*")

- The same with the pbuffer extension which as its glX counterpart

- and so on ... I won't have much time this week, but I would gladly
have tweaked this myself. Good luck :)