> I'm thinking to update mine to use Mesa3D and FreeGLUT,
> instead of the SGI OpenGL and GLUT that I currently have.
> i.e. use the newer open source versions, instead of the
> old and unmaintained vendor reference implementations...

On second thought, scratch that. It can die GL-1.2/GLUT-3.7,
better get Derelict/"Bud" limping along on Mac OS X instead.

--anders

Anders F Björklund wrote:
>> I'm thinking to update mine to use Mesa3D and FreeGLUT,
>> instead of the SGI OpenGL and GLUT that I currently have.
>> i.e. use the newer open source versions, instead of the
>> old and unmaintained vendor reference implementations...
> 
> On second thought, scratch that. It can die GL-1.2/GLUT-3.7,
> better get Derelict/"Bud" limping along on Mac OS X instead.
> 
> --anders

What's the problem, does bud not play nice with GDC or something?
Anyway fixing the MacOS X probs with bud/derelict sounds like the way to go that will have the most benefit for everyone including yourself in the long run.

--bb

Bill Baxter wrote:

> What's the problem, does bud not play nice with GDC or something?

It's mostly an educational problem, Bud requires the SVN version of GDC.

And for some reason it has a habit of placing my object files wrong...

> Anyway fixing the MacOS X probs with bud/derelict sounds like the way to go that will have the most benefit for everyone including yourself in the long run.

Actually I don't *need* more than GL 1.2 for the moment, so I'm good. :)

Will do the small D modules for GDC and Make, and Derelict for DMD/Bud.

--anders

Anders F Björklund wrote:
> James Pelcis wrote:
> 
>> Unless you need some of the extensions that aren't currently available with Derelict (I have all of them), I recommend you use Derelict instead.  Aldacron is doing a much better job at maintenance than I am.
> 
> And on the plus side, you don't have to use "std.loader" either.
> 
>> P.S.
>> summerseas.com isn't likely to be up for a while, as the server is between states and the destination doesn't have internet access right now.  If you still want the bindings, I can email them to you.
> 
> They were being linked to from:
> http://www.dsource.org/projects/bindings/wiki/SimpleDirectMediaLayer
> http://www.dsource.org/projects/bindings/wiki/OpenGraphicsLibrary
> http://www.dsource.org/projects/bindings/wiki/OpenAudioLibrary
> 
> Maybe your old files could be uploaded to the SVN there, instead ?
> http://www.dsource.org/projects/bindings/browser/trunk
> 
> --anders

The OpenGL and OpenAL files are uploaded.  I'm not going to be maintaining the SDL files anymore (and haven't updated them), so I didn't upload them.

James Pelcis wrote:

>> They were being linked to from:
>> http://www.dsource.org/projects/bindings/wiki/SimpleDirectMediaLayer
>> http://www.dsource.org/projects/bindings/wiki/OpenGraphicsLibrary
>> http://www.dsource.org/projects/bindings/wiki/OpenAudioLibrary
>>
>> Maybe your old files could be uploaded to the SVN there, instead ?
>> http://www.dsource.org/projects/bindings/browser/trunk
>>
> The OpenGL and OpenAL files are uploaded.  I'm not going to be maintaining the SDL files anymore (and haven't updated them), so I didn't upload them.

Thanks! Did you want to patch them to load the default frameworks
on Mac OS X / version(darwin), or isn't that platform supported ?

gl: ExeModule_Load("/System/Library/Frameworks/OpenGL.framework")
al: ExeModule_Load("/System/Library/Frameworks/OpenAL.framework")

glu: "/System/Library/Frameworks/OpenGL.framework"
glut: "/System/Library/Frameworks/GLUT.framework"

--anders

Anders F Björklund wrote:
> Thanks! Did you want to patch them to load the default frameworks
> on Mac OS X / version(darwin), or isn't that platform supported ?

I do indeed want to patch them (and I have).  I am willing to support OS X, but I don't have a Mac to do any of the testing on.

> gl: ExeModule_Load("/System/Library/Frameworks/OpenGL.framework")
> al: ExeModule_Load("/System/Library/Frameworks/OpenAL.framework")
> 
> glu: "/System/Library/Frameworks/OpenGL.framework"
> glut: "/System/Library/Frameworks/GLUT.framework"

Thanks.  That's committed now.  Is it right?

James Pelcis wrote:

> Thanks.  That's committed now.  Is it right?

Whaaaaaaaaa! ;-P

---
Paolo

James Pelcis wrote:

> I do indeed want to patch them (and I have).  I am willing to support OS X, but I don't have a Mac to do any of the testing on.
> 
> Thanks.  That's committed now.  Is it right?

Let's see now...

"gl.d:27: module glext cannot read file 'c/gl/glext.d'"

Right, they do need a subdirectory structure to match
(same as let-me-rearrange-your-source-files Java...)

"c/gl/_glextern.d:10: identifier 'GLvoid' is not defined
 c/gl/_glextern.d:10: GLvoid is used as a type"

Simple enough, lose the GLalias for that little file.

"gears.d:361: cannot implicitly convert expression (& idle) of type void(C *)() to void(*)()"

OK, lose my extern(C) on my callbacks - no problem

"gears.d:368: cannot implicitly convert expression (args) of type char[][] to int*"

No convenience wrapper for glutInit ? OK, argc/argv.


Unfortunately it won't link OK, though, since all the
function pointers have the same name as the symbols
from the OpenGL / GLUT system frameworks it seems ?

"ld: warning multiple definitions of symbol _glutBitmapCharacter
/var/tmp//ccBNPSeY.o definition of _glutBitmapCharacter in section (__DATA,__data)
/System/Library/Frameworks/GLUT.framework/GLUT(single module) definition of _glutBitmapCharacter
ld: warning multiple definitions of symbol _glutBitmapWidth
/var/tmp//ccBNPSeY.o definition of _glutBitmapWidth in section (__DATA,__data)
/System/Library/Frameworks/GLUT.framework/GLUT(single module) definition of _glutBitmapWidth
[...]
ld: warning multiple definitions of symbol _glActiveTexture
/var/tmp//ccDsucNC.o definition of _glActiveTexture in section (__DATA,__data)
/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib(gll_api.o) definition of _glActiveTexture
ld: warning multiple definitions of symbol _glAlphaFunc
/var/tmp//ccDsucNC.o definition of _glAlphaFunc in section (__DATA,__data)
/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib(gll_api.o) definition of _glAlphaFunc
[...]"

And then it throws a weird D run-time error at me:

"Error: circular initialization dependency with module gl"

So, no, I don't think that it is right just yet...
I'll stick with the import module, later Derelict.

--anders

Here is a new easy way to get going with OpenGL under D.

GLD, native D replacement for GLFW

GLD is a native D port of GLFW. It works on Windows and Linux, but has only been minimally tested using the example programs included.

By default, GLD directly links to OpenGL libraries. However, on Windows, it can optionally use the Derelict bindings for OpenGL. In the future, Derelict compatiblity may also be available on Linux.

GLD can be downloaded from http://www.baysmith.com/d/gld.zip

Since GLD is a direct port of GLFW, no documentation is provided. Instead, use the GLFW documentation. Simply subsitute gld for glfw and GLD for GLFW where necessary.

  Bradley


Bill Baxter wrote:
> What's the easiest way to get going with OpenGL under D?
> It seems like Derelict has OpenGL support using SDL, but I don't really like SDL's single-window limitation or draconian approach to window resizing (i.e. trash all your textures).
> 
> Are there other options?  What's the best supported / actively developed?
> 
> I was considering working on a GLUI-alike library.  GLUI is a simple, easy to use GUI library based on OpenGL.  It's pretty popular in the graphics research community just because it's so brain-dead easy to use, is very lightweight, and has very few dependencies.  Perfect for slapping a few buttons and sliders up on the screen to control your OpenGL program.  I think it could be very nice for D, since D is also all about ease-of-use.
> 
> --bb

Bradley Smith wrote:

> GLD, native D replacement for GLFW
> GLD is a native D port of GLFW. It works on Windows and Linux, but has only been minimally tested using the example programs included.

You know that the GLFW libary comes with bindings for D included, right?

> By default, GLD directly links to OpenGL libraries. However, on Windows, it can optionally use the Derelict bindings for OpenGL. In the future, Derelict compatiblity may also be available on Linux.

And in the even more distant future, it might also support Mac OS X... ?

--anders