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

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

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)

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.

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

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

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

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

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

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)
> #  ifdef GLUT_USE_SGI_OPENGL
> #   pragma comment (lib, "opengl.lib")    /* link with SGI OpenGL for Windows lib */
> #   pragma comment (lib, "glu.lib")       /* link with SGI OpenGL Utility lib */
> #   pragma comment (lib, "glut.lib")      /* link with Win32 GLUT for SGI OpenGL lib */
> #  else
> #   pragma comment (lib, "opengl32.lib")  /* link with Microsoft OpenGL lib */
> #   pragma comment (lib, "glu32.lib")     /* link with Microsoft OpenGL Utility lib */
> #   pragma comment (lib, "glut32.lib")    /* link with Win32 GLUT lib */
> #  endif

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