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)

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)

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

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

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

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.

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

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

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.

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