www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Module Naming (OpenGL/SDL)

reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
How are the modules for e.g. OpenGL / SDL
supposed to be named, in D ? (I know there's
another D project called "derelict", but it
doesn't work / isn't wanted just everywhere,
since it currently uses some Windows-only code)

I've seen some different module naming used...
So I thought I'd ask what the names "should" be ?


http://www.digitalmars.com/d/dstyle.html says:

 * Module
 Module names are all lower case.
 This avoids problems dealing
 with case insensitive file systems.
 
 * C Modules
 Modules that are interfaces to C functions
 go into the "c" package, for example:
 import std.c.stdio;
 
 Module names should be all lower case.


Does this mean that the .d modules should be in
c.gl and c.sdl then ? (to match the .h headers)

Or just go in directories gl and sdl (no "c.") ?
(especially if any new D code was added to them)


Should e.g. GLUT and SDL_image go in separate
packages, or be included in the gl and sdl ?

Should the OpenGL module be named opengl,
instead of the shorter-but-terser "gl" ?

Should the SDL files be named SDL_* still,
or be renamed for the .d module versions ?


Both seem to be working as they should...
(tried with "gears.d" and "testbitmap.d",
it needs a special SDLmain but that's it -
as Ds main must be called before SDLs main)

--anders


PS. Here are the C headers that were being used:


 #if defined(__APPLE__) && defined(__MACH__)
 #include <OpenGL/gl.h>
 #include <OpenGL/glext.h>
 #include <OpenGL/glu.h>
 #include <GLUT/glut.h>
 #elif !macintosh
 #include <GL/gl.h>
 #include <GL/glext.h>
 #include <GL/glu.h>
 #include <GL/glut.h>
 #else
 #include "gl.h"
 #include "glext.h"
 #include "glu.h"
 #include "glut.h"
 #endif


and


 #if defined(__APPLE__) && defined(__MACH__)
 #include <SDL/SDL.h>
 #include <SDL_image/SDL_image.h>
 #elif !macintosh
 #include <SDL/SDL.h>
 #include <SDL/SDL_image.h>
 #else
 #include "SDL.h"
 #include "SDL_image.h"
 #endif


(Mac OS X uses Frameworks, Mac OS 9 has no / paths)
Oct 17 2004
parent reply Daniel Horn <hellcatv hotmail.com> writes:
I wrote deliria (another dsource project) which doesn't do much but call 
some API functions

it's worlds easier to port openGL code if you write
glTexCoord2d
rahter than
gl.TexCoord2d
so I just put the full qualified name (as from the gl.h) into the file :-)
and that one is cross platform (lin,win)

svn.dsource.org/svn/projects/deliria/

Anders F Björklund wrote:

 How are the modules for e.g. OpenGL / SDL
 supposed to be named, in D ? (I know there's
 another D project called "derelict", but it
 doesn't work / isn't wanted just everywhere,
 since it currently uses some Windows-only code)
 
 I've seen some different module naming used...
 So I thought I'd ask what the names "should" be ?
 
 
 http://www.digitalmars.com/d/dstyle.html says:
 

 * Module
 Module names are all lower case.
 This avoids problems dealing
 with case insensitive file systems.

 * C Modules
 Modules that are interfaces to C functions
 go into the "c" package, for example:
 import std.c.stdio;

 Module names should be all lower case.


 
 
 Does this mean that the .d modules should be in
 c.gl and c.sdl then ? (to match the .h headers)
 
 Or just go in directories gl and sdl (no "c.") ?
 (especially if any new D code was added to them)
 
 
 Should e.g. GLUT and SDL_image go in separate
 packages, or be included in the gl and sdl ?
 
 Should the OpenGL module be named opengl,
 instead of the shorter-but-terser "gl" ?
 
 Should the SDL files be named SDL_* still,
 or be renamed for the .d module versions ?
 
 
 Both seem to be working as they should...
 (tried with "gears.d" and "testbitmap.d",
 it needs a special SDLmain but that's it -
 as Ds main must be called before SDLs main)
 
 --anders
 
 
 PS. Here are the C headers that were being used:
 

 #if defined(__APPLE__) && defined(__MACH__)
 #include <OpenGL/gl.h>
 #include <OpenGL/glext.h>
 #include <OpenGL/glu.h>
 #include <GLUT/glut.h>
 #elif !macintosh
 #include <GL/gl.h>
 #include <GL/glext.h>
 #include <GL/glu.h>
 #include <GL/glut.h>
 #else
 #include "gl.h"
 #include "glext.h"
 #include "glu.h"
 #include "glut.h"
 #endif


 
 
 and
 

 #if defined(__APPLE__) && defined(__MACH__)
 #include <SDL/SDL.h>
 #include <SDL_image/SDL_image.h>
 #elif !macintosh
 #include <SDL/SDL.h>
 #include <SDL/SDL_image.h>
 #else
 #include "SDL.h"
 #include "SDL_image.h"
 #endif


 
 
 (Mac OS X uses Frameworks, Mac OS 9 has no / paths)
Oct 17 2004
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Daniel Horn wrote:


 I wrote deliria (another dsource project) which doesn't
 do much but call some API functions


That was the functionality I was looking for, actually...

Perhaps it could be useful outside the deliria project ?


 it's worlds easier to port openGL code if you write
 glTexCoord2d
 rahter than
 gl.TexCoord2d
 so I just put the full qualified name (as from the gl.h) into the file :-)


Those modules (gl.d, glut.d) should be put in a package...

And you just have to import it, not any prefix functions.


 and that one is cross platform (lin,win)
 
 http://svn.dsource.org/svn/projects/deliria/


You can add "mac" (OS X) to the list, if you like. :-)

At least with some modifications, like taking the
glXGetProcAddressARB function call out of gl.d...

--anders
Oct 17 2004
next sibling parent reply Daniel Horn <hellcatv hotmail.com> writes:
excellent
I tried to sneak gl.d and glu.d and glee.d into deimos--not sure if 
they're still there ;-)

Anders F Björklund wrote:

 Daniel Horn wrote:
 

 I wrote deliria (another dsource project) which doesn't
 do much but call some API functions


 
 
 That was the functionality I was looking for, actually...
 
 Perhaps it could be useful outside the deliria project ?
 

 it's worlds easier to port openGL code if you write
 glTexCoord2d
 rahter than
 gl.TexCoord2d
 so I just put the full qualified name (as from the gl.h) into the file 
 :-)


 
 
 Those modules (gl.d, glut.d) should be put in a package...
 
 And you just have to import it, not any prefix functions.
 

 and that one is cross platform (lin,win)

 http://svn.dsource.org/svn/projects/deliria/


 
 
 You can add "mac" (OS X) to the list, if you like. :-)
 
 At least with some modifications, like taking the
 glXGetProcAddressARB function call out of gl.d...
 
 --anders
Oct 17 2004
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Daniel Horn wrote:


 I tried to sneak gl.d and glu.d and glee.d into deimos
 --not sure if they're still there ;-)


There seems to be something still under:
http://svn.dsource.org/svn/projects/deimos/trunk/etc/GL/
But it should probably be replaced by a separate one ?

I'm leaning towards something similar to Derelict,
but without all the pesky function pointer wrappers...
(i.e. opengl.gl and sdl.sdl - with GLUT / SDL_image)

Users can "weakly" load the function pointers themselves,
if they want that feature. And SDLmain still needs patching,
instead of doing a work-alike in D, like calling SDL_Init...

It's not much work updating the previous .d work to latest
versions of OpenGL and SDL, but maybe one should look into
auto-generating the D wrappers using one of the H2D tools ?

--anders
Oct 17 2004
prev sibling parent reply John Reimer <brk_6502 NOSP_AM.yahoo.com> writes:
Anders F Björklund wrote:

 Daniel Horn wrote:
 

 I wrote deliria (another dsource project) which doesn't
 do much but call some API functions


 
 
 That was the functionality I was looking for, actually...
 
 Perhaps it could be useful outside the deliria project ?
 

 it's worlds easier to port openGL code if you write
 glTexCoord2d
 rahter than
 gl.TexCoord2d
 so I just put the full qualified name (as from the gl.h) into the file 
 :-)


 
 
 Those modules (gl.d, glut.d) should be put in a package...
 
 And you just have to import it, not any prefix functions.
 

 and that one is cross platform (lin,win)

 http://svn.dsource.org/svn/projects/deliria/


 
 
 You can add "mac" (OS X) to the list, if you like. :-)
 
 At least with some modifications, like taking the
 glXGetProcAddressARB function call out of gl.d...
 
 --anders


Opengl is one of the most commonly interfaced libraries on D.  I find it 
strange that there still isn't a central repository for these basic 
libraries such that D programmers can just pick and choose them when 
they need them -- come to think of it, something like the Bindings 
project at dsource (which currently only includes d3d9).  Perhaps we 
should start contributing to that project.

There actually are complete opengl and sdl bindings available if you 
need it.

Take a look at the Japanese site: http://shinh.skr.jp/d/porting.html

Derelict is a great tool, and I really hope it continues to grow.  The 
linux version in the repository is not up-to-date from what hear.  There 
are actually a couple of people that have got the linux version pretty 
much operational, though.  The changes just haven't been submitted yet.

Yet, I do agree that there is still a need for the independent library 
bindings as well.
Oct 17 2004
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
John Reimer wrote:


 There actually are complete opengl and sdl bindings available if you 
 need it.
 
 Take a look at the Japanese site: http://shinh.skr.jp/d/porting.html


Only downsides being: no glut, bad naming of files, no packages.

The opengl is better in "deliria", but the sdl above is "OK"
(even if it needs some better names, and less Windows hacks)


 Derelict is a great tool, and I really hope it continues to grow.  The 
 linux version in the repository is not up-to-date from what hear.  There 
 are actually a couple of people that have got the linux version pretty 
 much operational, though.  The changes just haven't been submitted yet.


I'm using darwin (also known as Mac OS X), with the great gdc compiler.

OpenGL and SDL are both working great (based on deliria/shinh), just
trying to package it up as proper D modules so that it can be re-used ?

--anders
Oct 17 2004
next sibling parent reply John Reimer <brk_6502 NOSP_AM.yahoo.com> writes:
Anders F Björklund wrote:

 John Reimer wrote:
 

 There actually are complete opengl and sdl bindings available if you 
 need it.

 Take a look at the Japanese site: http://shinh.skr.jp/d/porting.html


 
 
 Only downsides being: no glut, bad naming of files, no packages.


Naming can always be changed :-).


 The opengl is better in "deliria", but the sdl above is "OK"
 (even if it needs some better names, and less Windows hacks)


Hmmm... looks like deliria does do a good job at the packaging.  They do 
seem to be cleaned up and well maintained.


 Derelict is a great tool, and I really hope it continues to grow.  The 
 linux version in the repository is not up-to-date from what hear.  
 There are actually a couple of people that have got the linux version 
 pretty much operational, though.  The changes just haven't been 
 submitted yet.


 
 
 I'm using darwin (also known as Mac OS X), with the great gdc compiler.
 
 OpenGL and SDL are both working great (based on deliria/shinh), just
 trying to package it up as proper D modules so that it can be re-used ?
 
 --anders


Great!  Good to see gdc is successfully being used on Darwin.  If you 
can get the opengl and sdl packaged up nicely, that would be wonderful. 
  Perhaps we can see about getting these placed in the bindings project 
at desource?  It would sure help people in the future since basic opengl 
and sdl functionality seems to be common request here.

Later,

John
Oct 17 2004
next sibling parent reply Daniel Horn <hellcatv hotmail.com> writes:
John Reimer wrote:

 Anders F Björklund wrote:
 

 John Reimer wrote:


 There actually are complete opengl and sdl bindings available if you 
 need it.

 Take a look at the Japanese site: http://shinh.skr.jp/d/porting.html




 Only downsides being: no glut, bad naming of files, no packages.


 
 
 Naming can always be changed :-).
 

 The opengl is better in "deliria", but the sdl above is "OK"
 (even if it needs some better names, and less Windows hacks)


 
 
 Hmmm... looks like deliria does do a good job at the packaging.  They do 
 seem to be cleaned up and well maintained.
 

 Derelict is a great tool, and I really hope it continues to grow.  
 The linux version in the repository is not up-to-date from what 
 hear.  There are actually a couple of people that have got the linux 
 version pretty much operational, though.  The changes just haven't 
 been submitted yet.




 I'm using darwin (also known as Mac OS X), with the great gdc compiler.

 OpenGL and SDL are both working great (based on deliria/shinh), just
 trying to package it up as proper D modules so that it can be re-used ?

 --anders


 
 
 Great!  Good to see gdc is successfully being used on Darwin.  If you 
 can get the opengl and sdl packaged up nicely, that would be wonderful. 
  Perhaps we can see about getting these placed in the bindings project 
 at desource?  It would sure help people in the future since basic opengl 
 and sdl functionality seems to be common request here.
 
 Later,
 
 John


Speaking of which...is gdc still stuck at the 0.8x series of D? Or is 
there some magic handwaving we can do to compile it with a newer D frontend.
I remember last time I used the gdc release(1f) I couldn't even make 
statically sized arrays without getting corrupted results.

--Daniel
Oct 17 2004
next sibling parent John Reimer <brk_6502 NOSP_AM.yahoo.com> writes:
 
 Speaking of which...is gdc still stuck at the 0.8x series of D? Or is 
 there some magic handwaving we can do to compile it with a newer D 
 frontend.
 I remember last time I used the gdc release(1f) I couldn't even make 
 statically sized arrays without getting corrupted results.
 
 --Daniel


 From his website... it looks to me that it's now at 1g.  It also says 
that it includes most of the functionality of 0.102.  Sounds like things 
are looking good!

I'm ashamed to say that I haven't yet tried gdc.  Once I get my Linux 
system fixed up again, I'll give it a go for sure.

His website is http://home.earthlink.net/~dvdfrdmn/d/
Oct 17 2004
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Daniel Horn wrote:


 Speaking of which...is gdc still stuck at the 0.8x series of D? Or is 
 there some magic handwaving we can do to compile it with a newer D 
 frontend.
 I remember last time I used the gdc release(1f) I couldn't even make 
 statically sized arrays without getting corrupted results.


Using the 1g release which has most of 0.102, with gcc version 3.4.2...

No major corruptions yet, except for the missing "long double" (on ppc)

--anders
Oct 17 2004
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
John Reimer wrote:


 Great!  Good to see gdc is successfully being used on Darwin.  If you 
 can get the opengl and sdl packaged up nicely, that would be wonderful. 
  Perhaps we can see about getting these placed in the bindings project 
 at desource?  It would sure help people in the future since basic opengl 
 and sdl functionality seems to be common request here.


Here is the proposed packaging:

opengl.gl	OpenGL 1.1 <sigh> headers (possibly 1.2.1?)
opengl.glu	OpenGL Utilities, matching the gl.d version

opengl.glext	Extensions to OpenGL, preferrably up to 1.5

opengl.wgl	Win32 GL functions: version(Windows)
opengl.glx	GLX, X Window System: version(unix)
opengl.agl	Mac OS 9 / Mac OS X CFM (both obsolete)
opengl.cgl	Core OpenGL, Mac OS X: version(darwin) *

opengl.wglext	Extensions to the Windows functions
opengl.glxext	Extensions to the Linux/UNIX functions

opengl.glut	GLUT, version 3.3 (possibly 3.7?)


Function pointers to extensions can be loaded with e.g. SDL...
(to access functionality beyond OpenGL 1.1, eg. from 1.2 - 1.5)

There are a *ton* of similar extension-loading libraries available.

It should be possible to do something like "version(GL_VERSION_1_2)"
in the module, corresponding to the C #defines in the .h headers ?

Could be populated when loading, by calling glGetString(GL_VERSION).

--anders


PS. * Theoretically, "darwin" could also be using the GLX routines
     if running eg. OpenDarwin with an X11 server and not Mac OS X...
     (or if compiling a X program for use with Apple's X11 server)
Oct 18 2004
next sibling parent John Reimer <brk_6502 NOSP_AM.yahoo.com> writes:
Anders F Björklund wrote:


 
 Here is the proposed packaging:
 
 opengl.gl    OpenGL 1.1 <sigh> headers (possibly 1.2.1?)
 opengl.glu    OpenGL Utilities, matching the gl.d version
 
 opengl.glext    Extensions to OpenGL, preferrably up to 1.5
 
 opengl.wgl    Win32 GL functions: version(Windows)
 opengl.glx    GLX, X Window System: version(unix)
 opengl.agl    Mac OS 9 / Mac OS X CFM (both obsolete)
 opengl.cgl    Core OpenGL, Mac OS X: version(darwin) *
 
 opengl.wglext    Extensions to the Windows functions
 opengl.glxext    Extensions to the Linux/UNIX functions
 
 opengl.glut    GLUT, version 3.3 (possibly 3.7?)


I like this package naming scheme.  Comments anyone?  Anders, Do you 
think you could submit it to the dsource Bindings project when you have 
it all ready?


 
 Function pointers to extensions can be loaded with e.g. SDL...
 (to access functionality beyond OpenGL 1.1, eg. from 1.2 - 1.5)
 
 There are a *ton* of similar extension-loading libraries available.
 
 It should be possible to do something like "version(GL_VERSION_1_2)"
 in the module, corresponding to the C #defines in the .h headers ?
 
 Could be populated when loading, by calling glGetString(GL_VERSION).
 
 --anders
 
 
 PS. * Theoretically, "darwin" could also be using the GLX routines
     if running eg. OpenDarwin with an X11 server and not Mac OS X...
     (or if compiling a X program for use with Apple's X11 server)



Looks promising!

Later,

John
Oct 18 2004
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
I wrote earlier:


 opengl.gl    OpenGL 1.1 <sigh> headers (possibly 1.2.1?)
 opengl.glu    OpenGL Utilities, matching the gl.d version


Since Microsoft is promoting "the other 3D API",
it means that they ship an ancient GL version...
(requiring people to use these function pointers)

This means they do gl 1.1 and glu 1.2, while the
Open Source SGI version is at gl 1.2.1 and glu 1.3...
(glut is vers 3.3 from MS, and glut 3.7 from SGI)


Situation solved something like this: (from GLUT)



lib */

*/

OpenGL lib */



Utility lib */




Where the SGI version is the default on
platforms other than Microsoft Windows...
(or later, like in Mac OS X system headers)


The headers themselves can be conditionalized/
versioned similarly, to support both at once.
(gl.h and glu.h, that is - and D counterparts)

With glext.h, *everyone* can go to OpenGL 1.5!
(possibly by using helpers, such as GLEE/GLEW)

All the modules are properly versioned for D:
version = GL_VERSION_1_2;
version = GLU_VERSION_1_3;
version = GLUT_API_VERSION_3;

--anders
Oct 18 2004
prev sibling parent John Reimer <brk_6502 NOSP_AM.yahoo.com> writes:
Another binding I'd like to see included at dsource is the opengl based 
glfw.  It's a much smaller/simpler library then sdl.  It's similar to 
glut but is much more powerful.
Oct 17 2004
prev sibling parent reply clayasaurus <clayasaurus gmail.com> writes:
John Reimer wrote:

 Anders F Björklund wrote:
 

 Daniel Horn wrote:


 I wrote deliria (another dsource project) which doesn't
 do much but call some API functions




 That was the functionality I was looking for, actually...

 Perhaps it could be useful outside the deliria project ?


 it's worlds easier to port openGL code if you write
 glTexCoord2d
 rahter than
 gl.TexCoord2d
 so I just put the full qualified name (as from the gl.h) into the 
 file :-)




 Those modules (gl.d, glut.d) should be put in a package...

 And you just have to import it, not any prefix functions.


 and that one is cross platform (lin,win)

 http://svn.dsource.org/svn/projects/deliria/




 You can add "mac" (OS X) to the list, if you like. :-)

 At least with some modifications, like taking the
 glXGetProcAddressARB function call out of gl.d...

 --anders


 
 
 Opengl is one of the most commonly interfaced libraries on D.  I find it 
 strange that there still isn't a central repository for these basic 
 libraries such that D programmers can just pick and choose them when 
 they need them -- come to think of it, something like the Bindings 
 project at dsource (which currently only includes d3d9).  Perhaps we 
 should start contributing to that project.
 
 There actually are complete opengl and sdl bindings available if you 
 need it.
 
 Take a look at the Japanese site: http://shinh.skr.jp/d/porting.html
 
 Derelict is a great tool, and I really hope it continues to grow.  The 
 linux version in the repository is not up-to-date from what hear.  There 
 are actually a couple of people that have got the linux version pretty 
 much operational, though.  The changes just haven't been submitted yet.
 
 Yet, I do agree that there is still a need for the independent library 
 bindings as well.


I've gotten Derelict to work on windows and linux for the most part 
(SDL,SDL_image,OpenGL,OpenGLU).

I havn't got OpenAL and I have yet to try SDL_mixer but it should work 
just like SDL_image.

Pretty much all you have to do for it to work on linux is include 
loader.d in your project somehow (or recompile phobos with it) after you 
fix the stupid version(Linux) --> version(linux)

then where it loads the windows dll, replace it with the linux shared 
library equivilent, in a version(linux), of course.
Oct 18 2004
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
clayasaurus wrote:


 I've gotten Derelict to work on windows and linux for the most part 
 (SDL,SDL_image,OpenGL,OpenGLU).
 
 I havn't got OpenAL and I have yet to try SDL_mixer but it should work 
 just like SDL_image.
 
 Pretty much all you have to do for it to work on linux is include 
 loader.d in your project somehow (or recompile phobos with it) after you 
 fix the stupid version(Linux) --> version(linux)
 
 then where it loads the windows dll, replace it with the linux shared 
 library equivilent, in a version(linux), of course.


But it still uses function pointer for *everything*, right ?

i.e. not only the Extensions for 1.2 - 1.5, but also GL 1.1 ?

--anders
Oct 18 2004
next sibling parent reply John Reimer <brk_6502 NOSP_AM.yahoo.com> writes:
Anders F Björklund wrote:

 clayasaurus wrote:
 

 I've gotten Derelict to work on windows and linux for the most part 
 (SDL,SDL_image,OpenGL,OpenGLU).

 I havn't got OpenAL and I have yet to try SDL_mixer but it should work 
 just like SDL_image.

 Pretty much all you have to do for it to work on linux is include 
 loader.d in your project somehow (or recompile phobos with it) after 
 you fix the stupid version(Linux) --> version(linux)

 then where it loads the windows dll, replace it with the linux shared 
 library equivilent, in a version(linux), of course.


 
 
 But it still uses function pointer for *everything*, right ?
 
 i.e. not only the Extensions for 1.2 - 1.5, but also GL 1.1 ?
 
 --anders


Yes, this is true, I believe, due to it's nature of not using a compile 
time link.  But you should be able to call these function "pointers" 
just like normal functions in D (unlike C).  So it shouldn't be too 
cumbersome beyond the current requirement of calling the shared library 
load function prior to using the functions (currently necessary for 
linux because of the inability to throw exceptions in the module 
constructor? -- don't know much about that issue) .  Of course, I 
haven't used the library myself yet, so perhaps I missed something?

But really, I think he was just responding to my interest in getting the 
linux version of Derelict up and running (currently a linux version is 
not available in the base project distribution).  Separate packaging of 
the opengl and sdl imports, as you were working on, is still of great 
usefulness.

- John
Oct 18 2004
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
John Reimer wrote:


 Yes, this is true, I believe, due to it's nature of not using a compile 
 time link.  But you should be able to call these function "pointers" 
 just like normal functions in D (unlike C).


You can call function pointers in C too, and take them too - I think ?

The compiler will (should?) insert the necessary (*p) and &p for you...


 But really, I think he was just responding to my interest in getting the 
 linux version of Derelict up and running (currently a linux version is 
 not available in the base project distribution).  Separate packaging of 
 the opengl and sdl imports, as you were working on, is still of great 
 usefulness.


One could wrap that in separate loaders, to make it easier to maintain ?

There is no point in having *two* wrapper projects, if they are similar.

--anders

PS. I think that wgl/glx/cgl should stay out of the core gl/glu + glut,
     since one could just use glut instead of those platform-specifics ?

     At least, it (wgl) should stay out of the "gl.d" module altogether!
     And while glext and glee are nice, they are kinda huge compared...
Oct 18 2004
parent reply John Reimer <brk_6502 NOSP_AM.yahoo.com> writes:
Anders F Björklund wrote:

 John Reimer wrote:
 

 Yes, this is true, I believe, due to it's nature of not using a 
 compile time link.  But you should be able to call these function 
 "pointers" just like normal functions in D (unlike C).


 
 
 You can call function pointers in C too, and take them too - I think ?
 
 The compiler will (should?) insert the necessary (*p) and &p for you...


Yes, I realize that C can call function pointers.  It's the manner in 
which these calls are made, that makes all the difference between C and D.

For example (using derelict as an example):

while C can only do (given that glViewport symbol is defined as a 
function pointer):

(*glViewport) (0, 0, 640, 480);

D can use the function directly:

glViewport( 0, 0, 640, 480 );

if glViewport has been defined as a function(GLint, Glint, GLsizei, 
GLsizei ).

It's much neater in D, I think.


 But really, I think he was just responding to my interest in getting 
 the linux version of Derelict up and running (currently a linux 
 version is not available in the base project distribution).  Separate 
 packaging of the opengl and sdl imports, as you were working on, is 
 still of great usefulness.


 
 
 One could wrap that in separate loaders, to make it easier to maintain ?
 
 There is no point in having *two* wrapper projects, if they are similar.


I don't think I understand you here.  Derelict is decidedly different in 
that it's purpose is to prevent you from having to use an import library 
  during the linking phase (very useful feature).  Yet for some of us, 
it may be still useful to have a "quick and dirty" C library linkage for 
experimentation.  Having the gl, glu, glut, and sdl available in there 
library linkage forms is still a useful project.  People tend to hunt 
around for these when they first come to D.


 --anders
 
 PS. I think that wgl/glx/cgl should stay out of the core gl/glu + glut,
     since one could just use glut instead of those platform-specifics ?
 
     At least, it (wgl) should stay out of the "gl.d" module altogether!
     And while glext and glee are nice, they are kinda huge compared...


Well, I liked your idea.  But remember, you can always use the "version" 
statements within gl and glu to accomplish the same purpose: 
version(Win32) and version (linux).
Oct 18 2004
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
John Reimer wrote:

While C can only do (given that glViewport symbol is defined as a

 function pointer):
 
 (*glViewport) (0, 0, 640, 480);
 
 D can use the function directly:
 
 glViewport( 0, 0, 640, 480 );
 
 if glViewport has been defined as a function(GLint, Glint, GLsizei, 
 GLsizei ).
 
 It's much neater in D, I think.


Could be a local C compiler dialect, but it does do the second version?
Either way, there is still a function pointer involved. (sugar or not)


 There is no point in having *two* wrapper projects, if they are similar.


 
 I don't think I understand you here.  Derelict is decidedly different in 
 that it's purpose is to prevent you from having to use an import library 
  during the linking phase (very useful feature).  Yet for some of us, it 
 may be still useful to have a "quick and dirty" C library linkage for 
 experimentation.  Having the gl, glu, glut, and sdl available in there 
 library linkage forms is still a useful project.  People tend to hunt 
 around for these when they first come to D.


What I meant was that the function-wrapping-project could link to the
simple-mapping-project, thus avoiding to do all the versioning and such?


 Well, I liked your idea.  But remember, you can always use the "version" 
 statements within gl and glu to accomplish the same purpose: 
 version(Win32) and version (linux).


That's how it works now. Makes for one big module, "hard" to divide...
I think it should be several modules, all within the same package.

--anders
Oct 18 2004
parent reply John Reimer <brk_6502 NOSP_AM.yahoo.com> writes:
Anders F Björklund wrote:

 John Reimer wrote:
 
 While C can only do (given that glViewport symbol is defined as a
 

 function pointer):

 (*glViewport) (0, 0, 640, 480);

 D can use the function directly:

 glViewport( 0, 0, 640, 480 );

 if glViewport has been defined as a function(GLint, Glint, GLsizei, 
 GLsizei ).

 It's much neater in D, I think.


 
 
 Could be a local C compiler dialect, but it does do the second version?
 Either way, there is still a function pointer involved. (sugar or not)


No, that was just me forgetting some basic C language concepts.  I must 
forgot how function pointers work in C  ... Sorry, it's been awhile 
since I've used pure C.  That was very polite of you to relate the issue 
to local C compiler dialect. :-)

As for the function pointer, why does it matter that it exists?  You 
don't notice it in your own application code.


 There is no point in having *two* wrapper projects, if they are similar.



 I don't think I understand you here.  Derelict is decidedly different 
 in that it's purpose is to prevent you from having to use an import 
 library  during the linking phase (very useful feature).  Yet for some 
 of us, it may be still useful to have a "quick and dirty" C library 
 linkage for experimentation.  Having the gl, glu, glut, and sdl 
 available in there library linkage forms is still a useful project.  
 People tend to hunt around for these when they first come to D.


 
 
 What I meant was that the function-wrapping-project could link to the
 simple-mapping-project, thus avoiding to do all the versioning and such?


Ah, I see.  Well that won't work properly with Derelict because of it's 
dependency on function pointers in this case.


 Well, I liked your idea.  But remember, you can always use the 
 "version" statements within gl and glu to accomplish the same purpose: 
 version(Win32) and version (linux).


 
 
 That's how it works now. Makes for one big module, "hard" to divide...
 I think it should be several modules, all within the same package.
 
 --anders


Okay, I understand what you are getting at.  I don't mind it either way, 
but I agree that your method makes things clearer.  Maybe some more 
opinions would be useful.

Later,

John
Oct 18 2004
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
John Reimer wrote:


 As for the function pointer, why does it matter that it exists?
 You don't notice it in your own application code.


I doubt the runtime "overhead" makes any impact at all...
(the function location has to be loaded from *somewhere*)

It mostly the *code* required to declare the pointer type,
the global for storing the pointer, and then populate it
using the proper platform version of loading the library...

However, it *already* needs that for versions above GL 1.1
so a nice side effect is that it does makes the OpenGL API
the same - no matter what GL version you are targetting...

Hey, wouldn't it be neat if one could weak-link functions ? ;-)


I guess one *could* make a version with function pointers
and then just stuff them all with &function, as a variant...

So I suppose best would be for the GL/SDL "projects" to merge.
But the function pointer types and their globals could still be
separate from the declaration of the C exports (from the libs) ?

Another thing is that OpenGL 1.5 contains a *huge* number of GL
extensions. (the glext.h *source code* is over 300KB/6000 lines)
Just doing 1.1 or 1.2 as a base, would make it a smaller lib.

But like I said, the function-pointer could just wrap the other?

--anders
Oct 18 2004
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
I find the function pointer way more convenient, due to three things:
- easier linking
- error diagnostics in case of missing libraries, even the possibility 
to try to load some other library; dynamic linking is your friend :)
- the extra options you have with function pointers; graphics engines 
especially use function pointers quite a lot, as it can make the render 
loops more flexible and powerful.

All-in-all; I'd use pointers over static linking any time. IMHO.

Lars Ivar Igesund

Anders F Björklund wrote:

 John Reimer wrote:
 

 As for the function pointer, why does it matter that it exists?
 You don't notice it in your own application code.


 
 
 I doubt the runtime "overhead" makes any impact at all...
 (the function location has to be loaded from *somewhere*)
 
 It mostly the *code* required to declare the pointer type,
 the global for storing the pointer, and then populate it
 using the proper platform version of loading the library...
 
 However, it *already* needs that for versions above GL 1.1
 so a nice side effect is that it does makes the OpenGL API
 the same - no matter what GL version you are targetting...
 
 Hey, wouldn't it be neat if one could weak-link functions ? ;-)
 
 
 I guess one *could* make a version with function pointers
 and then just stuff them all with &function, as a variant...
 
 So I suppose best would be for the GL/SDL "projects" to merge.
 But the function pointer types and their globals could still be
 separate from the declaration of the C exports (from the libs) ?
 
 Another thing is that OpenGL 1.5 contains a *huge* number of GL
 extensions. (the glext.h *source code* is over 300KB/6000 lines)
 Just doing 1.1 or 1.2 as a base, would make it a smaller lib.
 
 But like I said, the function-pointer could just wrap the other?
 
 --anders
Oct 18 2004
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Lars Ivar Igesund wrote:


 I find the function pointer way more convenient, due to three things:
 - easier linking


Albeit trickier to do cross-platform, or derelict would be up-to-date...


 - error diagnostics in case of missing libraries, even the possibility 
 to try to load some other library; dynamic linking is your friend :)


Well, you instead have the fun part of library versioning: "DLL Hell"


 - the extra options you have with function pointers; graphics engines 
 especially use function pointers quite a lot, as it can make the render 
 loops more flexible and powerful.


We were just talking about the OpenGL functions here, not in general.


 All-in-all; I'd use pointers over static linking any time. IMHO.


Function pointers are a nice addition, but they can be added on the
usual header ("static", or least directly-linked-to-a-dynamic-library)

It all looks like:

1) library function (optional)
extern (C) GLubyte * glGetString (GLenum name);

2) function pointer definition
extern (C) typedef GLubyte* function(GLenum) pfglGetString;

3) function pointer variable
pfglGetString           glGetString;

4) run-time loading from library
private void loadGL()
{
{
   glGetString = cast(pfglGetString)getProc("glGetString");
}
// throws Exception, if the symbol could not be found/loaded

5)
Lather, rinse, repeat... (a few hundred times)



Since the only thing usually provided "upstream" is number 1)
in form of a C header (.h) , it's at least three extra steps.

The only way to keep it remotely up-to-date is to automate,
but unfortunately H2D isn't all that self-going just yet...

It would be nice if there was some neat trick to get the
compiler or linker to do the dirty wrapping-and-loading ?

Managed languages like Java have some advantages here, even
if Sun has bungled it up badly with CLASSPATH and such cruft.


Meanwhile, we'll just use brute force. And lots of Perl. :-)
--anders
Oct 18 2004
next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Anders F Björklund wrote:


 Lars Ivar Igesund wrote:
 

 I find the function pointer way more convenient, due to three things:
 - easier linking


 
 
 Albeit trickier to do cross-platform, or derelict would be up-to-date...


Hmm, yes. The loader module in Phobos were supposed to rectify some of that.


 

 - error diagnostics in case of missing libraries, even the possibility 
 to try to load some other library; dynamic linking is your friend :)


 
 
 Well, you instead have the fun part of library versioning: "DLL Hell"


Don't you love it.


 

 - the extra options you have with function pointers; graphics engines 
 especially use function pointers quite a lot, as it can make the 
 render loops more flexible and powerful.


 
 
 We were just talking about the OpenGL functions here, not in general.


And wouldn't OpenGL be an important part of many graphics engines?

Lars Ivar Igesund
Oct 18 2004
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Lars Ivar Igesund wrote:


 Albeit trickier to do cross-platform, or derelict would be up-to-date...


 
 Hmm, yes. The loader module in Phobos were supposed to rectify some of 
 that.


Right, I just have to "port" it to Darwin (could use the SDL code?)


 Well, you instead have the fun part of library versioning: "DLL Hell"


 
 Don't you love it.


Don't have it here. Everyone lugs their own Frameworks around.
(Something about disk being cheap. System libs do exist, but
they're all controlled by the mothership - here being Mac OS X)


 We were just talking about the OpenGL functions here, not in general.


 
 And wouldn't OpenGL be an important part of many graphics engines?


Well, yes it would. But function pointers for the OpenGL 1.1 stuff ?

Either way, I'll just add the function pointer types to "my own" gl.d
(a friendly gnome had already added all of them to the glext header)

--anders
Oct 18 2004
prev sibling next sibling parent John Reimer <brk_6502 NOSP_AM.yahoo.com> writes:
Anders F Björklund wrote:

 Lars Ivar Igesund wrote:
 

 I find the function pointer way more convenient, due to three things:
 - easier linking


 
 
 Albeit trickier to do cross-platform, or derelict would be up-to-date...
 


Actually, the reason that derelict is not up-to-date on linux is not 
because of the trickiness of implementing this.  It's because the 
maintainer does not have a linux system and is not an active linux user. 
  So it was never a priority. Clayasaurus (what an alias, by the way! :) 
) and another person were able to get derelict working on Linux 
independently with what appears to be little effort.  From the C linking 
perspective, Linux is often a lot easier to deal with than windows.
Oct 18 2004
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
I wrote earlier:


 Function pointers are a nice addition, but they can be added on the
 usual header ("static", or least directly-linked-to-a-dynamic-library)
 
 It all looks like:
 
 1) library function (optional)
 extern (C) GLubyte * glGetString (GLenum name);
 
 2) function pointer definition
 extern (C) typedef GLubyte* function(GLenum) pfglGetString;


[...]

 5)
 Lather, rinse, repeat... (a few hundred times)



It was trivial to do with Perl...

They will follow the same syntax as glext:
alias GLubyte * (*PFGLGETSTRINGPROC) (GLenum name);

gl and glext are done, glu and glut will be shortly.

The original headers, ported to D just as they are...
(loading from library left for derelict / the reader)

--anders
Oct 18 2004
prev sibling parent reply Mike Parker <aldacron71 yahoo.com> writes:
Hi! I'm the Derelict guy :)


 
 But it still uses function pointer for *everything*, right ?
 
 i.e. not only the Extensions for 1.2 - 1.5, but also GL 1.1 ?
 
 --anders


Conceptually, there's no difference between using function pointers and 
linking to the import library (in which case you are using function 
pointers that the OS loads for you). The overhead is the same. And you 
still call gl* functions as normal.

I started Derelict in lieu of the existing bindings, primarily for my 
own ends, because the other bindings all *require* that you link to the 
import libs. I rarely do this in my own projects. On Windows, one of the 
most cryptic error messages you can get is 'A required DLL, some.dll, is 
missing'. By loading manually, you are able to catch and handle the 
exceptional case of a missing or corrupt DLL and respond in an 
app-specific manner. Then the user is not left gaping at the screen 
wondering what is going on.

One of the things the Quake 2 engine did with explicit dll loading was 
to have a separate set of debug functions that could be switched to at 
runtime from a console command. Calling qglVertex3f, for example, would 
then log the call before calling the real glVertex3f function (of 
course, there were two sets of function pointers for that setup - the 
qgl* functions and the gl* functions). The Torque engine (Tribes/Tribes 
2) uses this method to switch between opengl32.dll and a custom 
gl2d3d.dll at runtime for D3D rendering (a rather odd approach, but it 
works). Implicit linking would make both impossible to do.

I just find that this approach has more flexibility, and it means no 
extra work for the user (though it's a bear to code up in the first 
place). In C, I would normally put my OpenGL code in a DLL, link that 
implicitly with the opengl32 import lib, then load my DLL explicitly 
from the executable - then I wouldn't have to bother with all of the 
function pointers as the my DLL would fail to load if opengl were 
missing or corrupt. But with D I find this to be a bit awkward as the GC 
is statically linked to each executable/dll.

Anyway, regardless of whether official OpenGL/SDL/Python/whatever 
bindings crop up in Deimos or elsewhere, I intend to keep Derelict going 
as an alternative to implicit linkage for those who need it. That's wy 
it exists, that's why it uses function pointers, and I hope that clears 
up any confusion over it :)
Oct 18 2004
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Mike Parker wrote:


 Hi! I'm the Derelict guy :)


I'm a new guy, nice to meet you :-)


 Conceptually, there's no difference between using function pointers and 
 linking to the import library (in which case you are using function 
 pointers that the OS loads for you). The overhead is the same. And you 
 still call gl* functions as normal.


Yes, that much is similar. One *could* do a function loading context
instead of stuffing them as globals, but that means gl.gl___ calls...


 Anyway, regardless of whether official OpenGL/SDL/Python/whatever 
 bindings crop up in Deimos or elsewhere, I intend to keep Derelict going 
 as an alternative to implicit linkage for those who need it. That's wy 
 it exists, that's why it uses function pointers, and I hope that clears 
 up any confusion over it :)


I have done a simple way to wrap all of gl/glu and glut .h headers,
both all the "extern" C functions but also an alias for each pointer.

This means that you can include this and simplify the other code,
since the function prototypes are all *optional* (versioned)... ?

As discussed, one version of making both versions the very same is
to use &function instead of getProc("function") ? Same pointer var:

version (DYNAMIC) { p = cast(PFFUNCTIONPROC) getProc("function"); }
version (STATIC) { p = &function; }

So there is no conflict, just have to port the loader.d code to darwin
to have it use CFBundleGetFunctionPointerForName to load the functions.

--anders
Oct 19 2004
parent reply Mike Parker <aldacron71 yahoo.com> writes:
 As discussed, one version of making both versions the very same is
 to use &function instead of getProc("function") ? Same pointer var:
 
 version (DYNAMIC) { p = cast(PFFUNCTIONPROC) getProc("function"); }
 version (STATIC) { p = &function; }


That works, but then 'p' becomes a package-specific function name (such 
as the qgl* functions in the Quake engines). Additionally, you still 
need to declare the library function prototypes in the static version, 
in which case assigning a pointer becomes redundant. What about 
something like this:

version (DYNAMIC) // or EXPLICIT
{
typedef void function() pfmyfunc;
pfmyfunc myfunc;
myfunc = cast(pfmyfunc) getProc("myfunc");
}

version (STATIC) // or IMPLICIT
{
extern(C) void myfunc();
}

Just eliminate the function pointer in the implicitly loaded version.
Oct 19 2004
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Mike Parker wrote:


 As discussed, one version of making both versions the very same is
 to use &function instead of getProc("function") ? Same pointer var:

 version (DYNAMIC) { p = cast(PFFUNCTIONPROC) getProc("function"); }
 version (STATIC) { p = &function; }


 
 That works, but then 'p' becomes a package-specific function name (such 
 as the qgl* functions in the Quake engines).


Right, last time I used it was with a function pointer context class -
i.e. "context.p = &function;" (requires e.g. : "gl.glGetString" usage)

Besides the extra step to use it, this is nice because you can then
just load all the function pointers into a context hash at run-time...

Maybe it isn't such a hot idea ?



 Additionally, you still need to declare the library function
 prototypes in the static version, in which case assigning a pointer
 becomes redundant. What about something like this:
 
 version (DYNAMIC) // or EXPLICIT
 {
 typedef void function() pfmyfunc;
 pfmyfunc myfunc;
 myfunc = cast(pfmyfunc) getProc("myfunc");
 }
 
 version (STATIC) // or IMPLICIT
 {
 extern(C) void myfunc();
 }
 
 Just eliminate the function pointer in the implicitly loaded version.


Yeah, but that makes for two public versions ?
(one use regular functions, one using globals)


Here is what I ended up with for "opengl/gl.d":


 version (GL_GL_NO_PROTOTYPES) {} else {
 version = GL_GL_PROTOTYPES;
 }



 version (GL_GL_PROTOTYPES) {
 void glAccum (GLenum op, GLfloat value);
 void glAlphaFunc (GLenum func, GLclampf ref);
 ...
 }



 alias void (*PFGLACCUMPROC) (GLenum op, GLfloat value);
 alias void (*PFGLALPHAFUNCPROC) (GLenum func, GLclampf ref);
 ...


Which should reduce the dynamic/explicit/weak version to:


     version = GL_GL_NO_PROTOTYPES;
     import opengl.gl;


public: (globals)

     PFGLACCUMPROC glAccum;
     PFGLALPHAFUNCPROC glAlphaFunc;
     ...


private: (load function)

     glAccum          = cast(PFGLACCUMPROC) getProc("glAccum");
     glAlphaFunc      = cast(PFGLALPHAFUNCPROC) getProc("glAlphaFunc");
     ...


Which is easy to generate, from a list of function names ?


Also ported loader.d (such horrible code!) to Darwin,
with the mach-o dynamic libraries and NSModule bundles...

So now one can do this:

 hgl = ExeModule_Load("/System/Library/Frameworks/OpenGL.framework/OpenGL");


BTW; What is the path on Linux ? Just "/usr/lib/libGL.so" ?
(hoping for a final fix to the version: "linux" vs "Linux")

--anders


PS. There were a "couple" of other GL functions too. :-)
Oct 19 2004
parent Mike Parker <aldacron71 yahoo.com> writes:
Anders F Björklund wrote:

 
 Maybe it isn't such a hot idea ?
 


Actually, it's not a bad idea at all. But, I get the nagging feeling 
that it would be easier to leave things as two separate projects - one 
implicitly loaded and the other explicitly. I think implicit loading 
would be the normal desired behavior, and as such any 'official' 
opengl/sdl/whatever packages should be set up for that.


 
 BTW; What is the path on Linux ? Just "/usr/lib/libGL.so" ?
 (hoping for a final fix to the version: "linux" vs "Linux")
 


I have no clue, really. But I do believe it depends upon the distro.
Oct 19 2004
prev sibling parent John Reimer <brk_6502 NOSP_AM.yahoo.com> writes:
clayasaurus wrote:


 
 I've gotten Derelict to work on windows and linux for the most part 
 (SDL,SDL_image,OpenGL,OpenGLU).

 I havn't got OpenAL and I have yet to try SDL_mixer but it should work 
 just like SDL_image.
 
 Pretty much all you have to do for it to work on linux is include 
 loader.d in your project somehow (or recompile phobos with it) after you 
 fix the stupid version(Linux) --> version(linux)
 
 then where it loads the windows dll, replace it with the linux shared 
 library equivilent, in a version(linux), of course.
 


Thanks for the explanation.  I'll see if I can test this out once I've 
got my Linux up and running again.  I've played with loader.d before.  I 
still don't understand why the linux version is not compiled into phobos 
ATM.

Later,

John
Oct 18 2004