www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - headers for OpenGL, OpenAL, and SDL

reply Jamie Pelcis <jpelcis gmail.com> writes:
Here's a few headers for anyone who wants them, with the only license 
restriction from me being that I am in no way, shape, or form 
responsible for any problems.

OpenGL
http://www.summerseas.com/jpelcis/downloads/opengl.zip

OpenAL
http://www.summerseas.com/jpelcis/downloads/openal.zip

SDL
http://www.summerseas.com/jpelcis/downloads/sdl.zip


These are essentially untested, so please tell me if something goes wrong.

On a different note...
Walter, would you please replace std.loader?  If Mike Parker (Derelict 
project) doesn't mind you using his, it would be a good change.
Mar 04 2006
next sibling parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
Jamie Pelcis wrote:

 Here's a few headers for anyone who wants them, with the only license 
 restriction from me being that I am in no way, shape, or form 
 responsible for any problems.
 
 OpenGL
 http://www.summerseas.com/jpelcis/downloads/opengl.zip
 
 OpenAL
 http://www.summerseas.com/jpelcis/downloads/openal.zip
 
 SDL
 http://www.summerseas.com/jpelcis/downloads/sdl.zip
 
 
 These are essentially untested, so please tell me if something goes wrong.
 
 On a different note...
 Walter, would you please replace std.loader?  If Mike Parker (Derelict 
 project) doesn't mind you using his, it would be a good change.


Thanks!!
I've been looking for complete opengl headers for a while!
Mar 04 2006
prev sibling parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Jamie Pelcis wrote:

 Here's a few headers for anyone who wants them, with the only license 
 restriction from me being that I am in no way, shape, or form 
 responsible for any problems.
 
 OpenGL
 http://www.summerseas.com/jpelcis/downloads/opengl.zip
 
 OpenAL
 http://www.summerseas.com/jpelcis/downloads/openal.zip
 
 SDL
 http://www.summerseas.com/jpelcis/downloads/sdl.zip
 
 
 These are essentially untested, so please tell me if something goes wrong.
 
 On a different note...
 Walter, would you please replace std.loader?  If Mike Parker (Derelict 
 project) doesn't mind you using his, it would be a good change.


Hum, what are these headers different from those from Anders 
(http://www.algonet.se/~afb/d/) or from Dporting 
(http://shinh.skr.jp/d/porting.html) ?
(well, the SDL version seems more recent, but still looks like 
duplicated effort)


-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Mar 06 2006
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Bruno Medeiros wrote:


 Hum, what are these headers different from those from Anders 
 (http://www.algonet.se/~afb/d/) or from Dporting 
 (http://shinh.skr.jp/d/porting.html) ?
 (well, the SDL version seems more recent, but still looks like 
 duplicated effort)


 From what I can tell from it, there are some differences both
in general (i.e. "how") and in coverage/license (i.e. "what")


They seem to be using the same kind of function pointers as
in Derelict, while my headers linked directly to the C libs...

i.e. the import module contains global function pointer entries,
and these are loaded from the DLL/SO at startup with std.loader

And these are in c.sdl and c.gl, mine were in sdl and opengl.
(there are also the derelict.sdl and derelict.opengl modules)


These OpenGL headers are based on Mesa 3-D and FreeGLUT, while
I used the SGI OpenGL 1.2.1 and GLUT 3.7 (both from opengl.org)

The licenses on these Open Source versions are much "nicer" than
the old ones, so that is really a good thing. They're newer, too.

They also included the GLX, WGL and AGL [empty now] extensions,
while I only included the GL/GLUT cross-platform variants in mine.


Oh, and these new ones don't support the Mac yet (maybe just Windows ?)
Tested mine (before) without any problems on Mac OS X, Linux and MinGW.

It's possible to add Mac support to these; by completing the AGL module,
and by adding support for calling the "SDL_main" hack (as usual) to SDL.

But I don't care much for the function pointers, though. Sorry... :-)
Understand they are handy on Windows, when you don't have the implibs.

--anders


PS.
I have SDL 1.2.9 in the CVS, so there shouldn't be any version diff ?
Haven't gotten around to updating the ZIPs, or fixing the DMD linking.
Mar 06 2006
parent reply James Pelcis <jpelcis gmail.com> writes:
I thought it would be a good idea to put things that are ported into the 
c namespace.  If the project ever gets a pure D implementation, it 
wouldn't conflict with programs written for the c version.

If someone gives me the AGL header, I'll see what I can do to take care 
of it, too.

I'm not sure exactly what you're asking in the ps, but mine should work 
with 1.2.9.

Anders F Björklund wrote:

 Bruno Medeiros wrote:
 

 Hum, what are these headers different from those from Anders 
 (http://www.algonet.se/~afb/d/) or from Dporting 
 (http://shinh.skr.jp/d/porting.html) ?
 (well, the SDL version seems more recent, but still looks like 
 duplicated effort)


 
  From what I can tell from it, there are some differences both
 in general (i.e. "how") and in coverage/license (i.e. "what")
 
 
 They seem to be using the same kind of function pointers as
 in Derelict, while my headers linked directly to the C libs...
 
 i.e. the import module contains global function pointer entries,
 and these are loaded from the DLL/SO at startup with std.loader
 
 And these are in c.sdl and c.gl, mine were in sdl and opengl.
 (there are also the derelict.sdl and derelict.opengl modules)
 
 
 These OpenGL headers are based on Mesa 3-D and FreeGLUT, while
 I used the SGI OpenGL 1.2.1 and GLUT 3.7 (both from opengl.org)
 
 The licenses on these Open Source versions are much "nicer" than
 the old ones, so that is really a good thing. They're newer, too.
 
 They also included the GLX, WGL and AGL [empty now] extensions,
 while I only included the GL/GLUT cross-platform variants in mine.
 
 
 Oh, and these new ones don't support the Mac yet (maybe just Windows ?)
 Tested mine (before) without any problems on Mac OS X, Linux and MinGW.
 
 It's possible to add Mac support to these; by completing the AGL module,
 and by adding support for calling the "SDL_main" hack (as usual) to SDL.
 
 But I don't care much for the function pointers, though. Sorry... :-)
 Understand they are handy on Windows, when you don't have the implibs.
 
 --anders
 
 
 PS.
 I have SDL 1.2.9 in the CVS, so there shouldn't be any version diff ?
 Haven't gotten around to updating the ZIPs, or fixing the DMD linking.
Mar 06 2006
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
James Pelcis wrote:


 I thought it would be a good idea to put things that are ported into the 
 c namespace.  If the project ever gets a pure D implementation, it 
 wouldn't conflict with programs written for the c version.


Well, I think it was "supposed" to go in the etc.c (Deimos) namespace -
but since there was never any guidelines I just went with the shorter...


 If someone gives me the AGL header, I'll see what I can do to take care 
 of it, too.


It's copyrighted by Apple, but should be straightforward to translate...
Located in /System/Library/Frameworks/AGL.framework/Headers/agl.h on OSX

Distributing Apple system headers has the same issues as Win32 headers,
but without any "w32api" version like available for the MinGW compiler.

The GL library location is /System/Library/Frameworks/OpenGL.framework,
by the way (i.e. same as "OpenGL32.dll" or "libGLX.so", but without AGL)


 I'm not sure exactly what you're asking in the ps, but mine should work 
 with 1.2.9.


Oh, I was just meaning that I had SDL 1.2.8 as ZIP - but 1.2.9 in CVS.
Apparently the implibs I bundled weren't working for DMD/Windows either

--anders
Mar 06 2006
parent reply James Pelcis <jpelcis gmail.com> writes:
Let me put this a different way...  I don't have a Mac, so I don't have 
a copy of the header.  I would still be more than happy to port it though.

The SDL 1.2.9 interface is either a superset of 1.2.8 or exactly the 
same, but I'm not sure which.  I'd try using your CVS version with an 
older version of the library to find out for sure.  If it works, assume 
that there is no version difference.

What's the official "version (Mac)?"

Anders F Björklund wrote:

 James Pelcis wrote:
 

 I thought it would be a good idea to put things that are ported into 
 the c namespace.  If the project ever gets a pure D implementation, it 
 wouldn't conflict with programs written for the c version.


 
 Well, I think it was "supposed" to go in the etc.c (Deimos) namespace -
 but since there was never any guidelines I just went with the shorter...
 

 If someone gives me the AGL header, I'll see what I can do to take 
 care of it, too.


 
 It's copyrighted by Apple, but should be straightforward to translate...
 Located in /System/Library/Frameworks/AGL.framework/Headers/agl.h on OSX
 
 Distributing Apple system headers has the same issues as Win32 headers,
 but without any "w32api" version like available for the MinGW compiler.
 
 The GL library location is /System/Library/Frameworks/OpenGL.framework,
 by the way (i.e. same as "OpenGL32.dll" or "libGLX.so", but without AGL)
 

 I'm not sure exactly what you're asking in the ps, but mine should 
 work with 1.2.9.


 
 Oh, I was just meaning that I had SDL 1.2.8 as ZIP - but 1.2.9 in CVS.
 Apparently the implibs I bundled weren't working for DMD/Windows either
 
 --anders
Mar 06 2006
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
James Pelcis wrote:


 Let me put this a different way...  I don't have a Mac, so I don't have 
 a copy of the header.  I would still be more than happy to port it though.


And that is the problem. Without a Mac, you don't have the original 
headers and they can't be-redistributed without permission from Apple...

For SWT on Mac OS X for instance, they have a special "license" for it


 The SDL 1.2.9 interface is either a superset of 1.2.8 or exactly the 
 same, but I'm not sure which.  I'd try using your CVS version with an 
 older version of the library to find out for sure.  If it works, assume 
 that there is no version difference.


I just ran a diff on the headers from 1.2.8 to 1.2.9 and applied it...
As I recall it, there was just cosmetical differences - no API changes.


 What's the official "version (Mac)?"


version(darwin)

Only problem that it is valid both for Darwin (which runs X11, and GLX)
and for Mac OS X (which runs Quartz and AGL). But it's usually Mac OS X.

--anders
Mar 07 2006
parent reply James Pelcis <jpelcis gmail.com> writes:
Would derivative works still be under the same non-redistributable 
license?  If so, there is no point in porting it.

Anders F Björklund wrote:

 And that is the problem. Without a Mac, you don't have the original 
 headers and they can't be-redistributed without permission from Apple...
Mar 07 2006
parent reply James Pelcis <jpelcis gmail.com> writes:
If http://darcs.brianweb.net/vendor/powerpc-apple-darwin/include/ is 
legal, then so is a port of AGL.  The updated version on the website 
should have most of it, but I had trouble finding the information on 
Style.  Would someone with a Mac (hi Anders) please test it?  Thank you!

James Pelcis wrote:

 Would derivative works still be under the same non-redistributable 
 license?  If so, there is no point in porting it.
 
 Anders F Björklund wrote:

 And that is the problem. Without a Mac, you don't have the original 
 headers and they can't be-redistributed without permission from Apple...
Mar 07 2006
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
James Pelcis wrote:


 If http://darcs.brianweb.net/vendor/powerpc-apple-darwin/include/ is 
 legal, then so is a port of AGL. 


Yeah, so that only leaves the question: is it ? :-)


 The updated version on the website 
 should have most of it, but I had trouble finding the information on 
 Style.  Would someone with a Mac (hi Anders) please test it?  Thank you!


Hmm, not sure how I would test it without the rest of Carbon ?
But maybe I can use my old hello world to get an AGL window up...

Anyway, here are two bugs meanwhile:

c/gl/glext.d:2868: glTexCoord2fColor4fNormal3fVertex3fSUN is used as a type
c/gl/glext.d:2868: variable 
c.gl.glext._staticCtor.glTexCoord2fColor4fNormal3fVertex3fSUN voids have 
no value
c/gl/glext.d:2869: cannot implicitly convert expression (cast(void(C 
*)(float, float, float, float, float, float, float, float, float, float, 
float, float))(getProc("glTexCoord2fColor4fNormal3fVertex3fSUN"))) of 
type pfglTexCoord2fColor4fNormal3fVertex3fSUN to int

c/gl/glext.d:3308: glGetFramebufferAttachmentParameterivEXT is used as a 
type
c/gl/glext.d:3308: variable 
c.gl.glext._staticCtor.glGetFramebufferAttachmentParameterivEXT voids 
have no value
c/gl/glext.d:3309: cannot implicitly convert expression (cast(void(C 
*)(uint, uint, uint, 
int*))(getProc("glGetFramebufferAttachmentParameterivEXT"))) of type 
pfglGetFramebufferAttachmentParameterivEXT to int

You'll notice I had to move all the D sources, before it compiled...
(they are supposed to go in a c/gl subdirectory, to match the module)

--anders
Mar 07 2006
parent James Pelcis <jpelcis gmail.com> writes:
Thanks for the help.  I think everything works.  The glext errors were 
caused by the partial failure of a regex.  I think everything works, but 
it would be nice if you could get that "Hello World" in AGL.

Anders F Björklund wrote:

 James Pelcis wrote:
 

 If http://darcs.brianweb.net/vendor/powerpc-apple-darwin/include/ is 
 legal, then so is a port of AGL. 


 
 Yeah, so that only leaves the question: is it ? :-)
 

 The updated version on the website should have most of it, but I had 
 trouble finding the information on Style.  Would someone with a Mac 
 (hi Anders) please test it?  Thank you!


 
 Hmm, not sure how I would test it without the rest of Carbon ?
 But maybe I can use my old hello world to get an AGL window up...
 
 Anyway, here are two bugs meanwhile:
 
 c/gl/glext.d:2868: glTexCoord2fColor4fNormal3fVertex3fSUN is used as a type
 c/gl/glext.d:2868: variable 
 c.gl.glext._staticCtor.glTexCoord2fColor4fNormal3fVertex3fSUN voids have 
 no value
 c/gl/glext.d:2869: cannot implicitly convert expression (cast(void(C 
 *)(float, float, float, float, float, float, float, float, float, float, 
 float, float))(getProc("glTexCoord2fColor4fNormal3fVertex3fSUN"))) of 
 type pfglTexCoord2fColor4fNormal3fVertex3fSUN to int
 
 c/gl/glext.d:3308: glGetFramebufferAttachmentParameterivEXT is used as a 
 type
 c/gl/glext.d:3308: variable 
 c.gl.glext._staticCtor.glGetFramebufferAttachmentParameterivEXT voids 
 have no value
 c/gl/glext.d:3309: cannot implicitly convert expression (cast(void(C 
 *)(uint, uint, uint, 
 int*))(getProc("glGetFramebufferAttachmentParameterivEXT"))) of type 
 pfglGetFramebufferAttachmentParameterivEXT to int
 
 You'll notice I had to move all the D sources, before it compiled...
 (they are supposed to go in a c/gl subdirectory, to match the module)
 
 --anders
Mar 08 2006
prev sibling next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
James Pelcis wrote:


 but I had trouble finding the information on Style.


That would be an oldskool Mac type:

// Quickdraw font rendering styles
alias ubyte Style;
alias short StyleParameter;
alias Style StyleField;

Part of <CarbonCore/MacTypes.h>

--anders
Mar 07 2006
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
James Pelcis wrote:


 Would someone with a Mac (hi Anders) please test it?  Thank you!


Also, there was a (C) declaration missed on the glut fonts:

ld: Undefined symbols:
__D1c2gl4glut15glutBitmap8By13Pv
__D1c2gl4glut15glutBitmap9By15Pv
__D1c2gl4glut15glutStrokeRomanPv
__D1c2gl4glut19glutStrokeMonoRomanPv
__D1c2gl4glut21glutBitmapHelvetica10Pv
__D1c2gl4glut21glutBitmapHelvetica12Pv
__D1c2gl4glut21glutBitmapHelvetica18Pv
__D1c2gl4glut22glutBitmapTimesRoman10Pv
__D1c2gl4glut22glutBitmapTimesRoman24Pv

Should be declared like this:

	extern (C) GLvoid* glutStrokeRoman;

Otherwise they get D mangling.


You can't declare them in the D import module either,
since then it won't link to the external ones from C ?

i.e. they should go into a separate "glutextern.d" file

--anders


PS.
Doesn't seem to start, though:
Error: circular initialization dependency with module gl
Not sure what that is all about.
Mar 08 2006
prev sibling parent reply James Pelcis <jpelcis gmail.com> writes:
The primary differences are the version and what is included.  The 
versions should be OpenGL 2.0, GLU 1.3, GLX 1.4, FreeGLUT 2.4.0 
(includes the latest GLUT), OpenAL 1.1, and SDL 1.2.9.

If I remember right, the GLext is actually more up-to-date than the 
official C/C++ one.

Aside from that, you're right about the duplicated effort.  We need more 
of a central repository for translated headers than currently exists (no 
offense meant to dsource).

Bruno Medeiros wrote:

 Jamie Pelcis wrote:

 Here's a few headers for anyone who wants them, with the only license 
 restriction from me being that I am in no way, shape, or form 
 responsible for any problems.

 OpenGL
 http://www.summerseas.com/jpelcis/downloads/opengl.zip

 OpenAL
 http://www.summerseas.com/jpelcis/downloads/openal.zip

 SDL
 http://www.summerseas.com/jpelcis/downloads/sdl.zip


 These are essentially untested, so please tell me if something goes 
 wrong.

 On a different note...
 Walter, would you please replace std.loader?  If Mike Parker (Derelict 
 project) doesn't mind you using his, it would be a good change.


 
 Hum, what are these headers different from those from Anders 
 (http://www.algonet.se/~afb/d/) or from Dporting 
 (http://shinh.skr.jp/d/porting.html) ?
 (well, the SDL version seems more recent, but still looks like 
 duplicated effort)
Mar 06 2006
parent reply Don Clugston <dac nospam.com.au> writes:
James Pelcis wrote:

 Aside from that, you're right about the duplicated effort.  We need more 
 of a central repository for translated headers than currently exists (no 
 offense meant to dsource).


I have a grandiose scheme for a C2D project, where rather than storing 
the converted headers (with associated licensing issues), we instead 
store the 'script' (actually more of a hint file) that was used for 
conversion.
It would be fantastic to accumulate a database of C2D files.

Sample C2D script format (excerpt of part of the one that converts the 
Win SDK headers). There are a few other sections, apart from those shown 
here. The C2D program can't do the full Win SDK yet (I'm currently 
working out what to do with bitfields in structs), but it's OK for 
fairly simple headers right now.
====================================
; comments start with a semicolon
; --- The following ones are only for MingW ---
#REMOVE
AbnormalTermination

; --- These are common to both Microsoft and MingW ---

; these macros get removed entirely
#REMOVE
MAKEINTATOM
DefineHandleTable
FreeProcInstance
GetFreeSpace
LimitEmsPages

; these macros are replaced with inline functions
#MACRO
RtlFillMemory
  void RtlFillMemory(void* d, uint len, ubyte f){ memset(d, f, len); }
FreeModule
  alias FreeLibrary FreeModule;
HasOverlappedIoCompleted
  bool HasOverlappedIoCompleted(LPOVERLAPPED lpOverlapped){
   return (*lpOverlapped).Internal != STATUS_PENDING;
  }

; these '#if's get turned into version(xxx) {
#VERSION
(_WIN32_WINNT >= 0x0500)
  version(WinXP)
Mar 07 2006
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Don Clugston wrote:


 I have a grandiose scheme for a C2D project, where rather than storing 
 the converted headers (with associated licensing issues), we instead 
 store the 'script' (actually more of a hint file) that was used for 
 conversion.


Arguably, if those "scripts" are verbose enough they could be
subject to the very same licensing issues as the header files... :-(

But it would be neat to have for the old Mac OS headers (i.e. Carbon),
in addition to the full Win32 SDK headers that I gather you're doing.


 It would be fantastic to accumulate a database of C2D files.


Or have a better tool ? I guess you've looked at SWIG, by the way ?


 Sample C2D script format (excerpt of part of the one that converts the 
 Win SDK headers). There are a few other sections, apart from those shown 
 here. The C2D program can't do the full Win SDK yet (I'm currently 
 working out what to do with bitfields in structs), but it's OK for 
 fairly simple headers right now.


Bitfields usually means writing wrapper accessors/mutators...
But I guess that would be a bit hard to do automated, right ?

The Perl hack I used is at http://www.algonet.se/~afb/d/h2d.pl
It doesn't preprocess and it doesn't parse. It just replaces...

But I've successfully used it for "step one" in translating.

--anders
Mar 07 2006
parent reply Don Clugston <dac nospam.com.au> writes:
Anders F Björklund wrote:

 Don Clugston wrote:
 

 I have a grandiose scheme for a C2D project, where rather than storing 
 the converted headers (with associated licensing issues), we instead 
 store the 'script' (actually more of a hint file) that was used for 
 conversion.


 
 Arguably, if those "scripts" are verbose enough they could be
 subject to the very same licensing issues as the header files... :-(


I guess that's possible, but they'll have very little information in 
them. Typically, just the names of a couple of the #defines, most of 
which are listed in external documentation, and which are used in 
samples. It's not a problem for the Windows SDK, because the MingW 
header script seems to work with the Microsoft files, too. I'm not sure 
about Carbon, though.
In any case, it will be clear that the source is not being redistributed.

Actually, though, my primary intention is to be able to keep up with 
open-source header changes, rather than avoid the license issues.


 But it would be neat to have for the old Mac OS headers (i.e. Carbon),
 in addition to the full Win32 SDK headers that I gather you're doing.



 It would be fantastic to accumulate a database of C2D files.


 
 Or have a better tool ? I guess you've looked at SWIG, by the way ?


Yes, it would be good to leverage off something else. Unfortunately, it 
seems that SWIG requires you to modify the header file. It would 
definitely be the way to go for C++ code, though.


 Sample C2D script format (excerpt of part of the one that converts the 
 Win SDK headers). There are a few other sections, apart from those 
 shown here. The C2D program can't do the full Win SDK yet (I'm 
 currently working out what to do with bitfields in structs), but it's 
 OK for fairly simple headers right now.


 
 Bitfields usually means writing wrapper accessors/mutators...
 But I guess that would be a bit hard to do automated, right ?


It's tricky, but possible. I might just cheat and require them to be 
defined manually for now.


 The Perl hack I used is at http://www.algonet.se/~afb/d/h2d.pl
 It doesn't preprocess and it doesn't parse. It just replaces...


C isn't too difficult to parse, fortunately. And _perfect_ parsing 
doesn't seem to be necessary (there's a huge advantage in knowing that 
the code is valid C).
Mar 07 2006
parent James Pelcis <jpelcis gmail.com> writes:
Keeping up with the changes isn't normally a big deal (although there 
are exceptions).  It's getting it done the first time.

Don Clugston wrote:

 Actually, though, my primary intention is to be able to keep up with 
 open-source header changes, rather than avoid the license issues.


Fortunately many of the larger projects attempt to make their headers as 
simple as possible to make sure all compilers will treat it the same.  A 
problem may arise from different conventions on how to make code look 
good though.


 C isn't too difficult to parse, fortunately. And _perfect_ parsing 
 doesn't seem to be necessary (there's a huge advantage in knowing that 
 the code is valid C).


That makes it all worth it!

Anders F Björklund wrote:

 But I've successfully used it for "step one" in translating.
Mar 07 2006