www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Getting going with D/OpenGL

reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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
Oct 22 2006
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Bill Baxter wrote:


 What's the easiest way to get going with OpenGL under D?


Use either e.g. Derelict's loaders, or the OpenGL import modules:

http://www.dsource.org/projects/derelict/
http://www.dsource.org/projects/bindings/
http://shinh.skr.jp/d/porting.html
http://www.algonet.se/~afb/d/

One approach uses function pointers and loads symbols at runtime,
while the other links directly to the libraries (as in C or C++).

I will be bundling my modules for SDL and GL with my GDC builds,
and wxD now has preliminary samples for using SDL and GL, as well.

import sdl.sdl;
import gl.gl;


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


You don't have to use SDL to use GL, but you can if you like.
(i.e. SDL can use GL, but you can go directly to GL instead...)


 Are there other options?  What's the best supported / actively developed?


Both of the two approaches mentioned above are still supported.


 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.


Yes, GLUI would work fine for D. And GLUT can also be used,
if you only need a simple GL window and not a full "GUI" ?

There is also the GLFW project: http://glfw.sourceforge.net/

--anders
Oct 23 2006
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Anders F Björklund wrote:

 Bill Baxter wrote:
 

 What's the easiest way to get going with OpenGL under D?


 
 Use either e.g. Derelict's loaders, or the OpenGL import modules:
 
 http://www.dsource.org/projects/derelict/
 http://www.dsource.org/projects/bindings/
 http://shinh.skr.jp/d/porting.html
 http://www.algonet.se/~afb/d/
 
 One approach uses function pointers and loads symbols at runtime,
 while the other links directly to the libraries (as in C or C++).


Which is which?  Do they all support OpenGL 2.0?  Looks like Derelict 
does now.  Are there any conflicts from having them all installed (e.g. 
does more than one want to be called gl.gl)?  Any 
performance/functionality differences?


 I will be bundling my modules for SDL and GL with my GDC builds,
 and wxD now has preliminary samples for using SDL and GL, as well.
 
 import sdl.sdl;
 import gl.gl;
 

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


 
 You don't have to use SDL to use GL, but you can if you like.
 (i.e. SDL can use GL, but you can go directly to GL instead...)


Ah, but I do like the SDL's cross-platform goodness.  Certain don't want 
to bother with a bunch of wgl-ing or WinMain-ing to get an otherwise 
platform neutral GL app up and running.

[...]

 Yes, GLUI would work fine for D. And GLUT can also be used,
 if you only need a simple GL window and not a full "GUI" ?


I was thinking more of rewriting something "GLUI-like" in D rather than 
actually wrapping GLUI.  GLUI depends on GLUT for its windowing and 
input which is kinda annoying, since GLUT has some problems.  And the 
GLUI code's concept of OO is ... interesting.  Ideally the input/window 
interface would be abstracted a little bit, so the toolkit could work on 
top of SDL, for example (albeit single-windowed) or GLUT, or GLFW.  And 
maybe I'd like to add some simple theming, too.  Not everybody's crazy 
about the Win95 look 'n' feel, after all. :-)



 There is also the GLFW project: http://glfw.sourceforge.net/
Oct 23 2006
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Bill Baxter wrote:


 Use either e.g. Derelict's loaders, or the OpenGL import modules:

 http://www.dsource.org/projects/derelict/
 http://www.dsource.org/projects/bindings/
 http://shinh.skr.jp/d/porting.html
 http://www.algonet.se/~afb/d/

 One approach uses function pointers and loads symbols at runtime,
 while the other links directly to the libraries (as in C or C++).


 
 Which is which?  Do they all support OpenGL 2.0?  Looks like Derelict 
 does now.  Are there any conflicts from having them all installed (e.g. 
 does more than one want to be called gl.gl)?  Any 
 performance/functionality differences?


Let's see now, the first two uses loaders and the second two linking.

They all live in different D namespaces, even though I think all of
the modules based on DedicateD's use the sdl.sdl/[open]gl.gl naming ?

There is a minor cost in space for the function pointers and startup
loading time, but that shouldn't make any difference in actual use...

I just use the import modules directly, since I find it to be easier.
(especially on platforms like Mac, without DMD and Build easy to use)


 You don't have to use SDL to use GL, but you can if you like.
 (i.e. SDL can use GL, but you can go directly to GL instead...)


 
 Ah, but I do like the SDL's cross-platform goodness.  Certain don't want 
 to bother with a bunch of wgl-ing or WinMain-ing to get an otherwise 
 platform neutral GL app up and running.


No, but it is much easier to just use GLUT or GLFW for that...


 I was thinking more of rewriting something "GLUI-like" in D rather than 
 actually wrapping GLUI.  GLUI depends on GLUT for its windowing and 
 input which is kinda annoying, since GLUT has some problems.  And the 
 GLUI code's concept of OO is ... interesting.  Ideally the input/window 
 interface would be abstracted a little bit, so the toolkit could work on 
 top of SDL, for example (albeit single-windowed) or GLUT, or GLFW.  And 
 maybe I'd like to add some simple theming, too.  Not everybody's crazy 
 about the Win95 look 'n' feel, after all. :-)


No, something themable would be nice - I agree with you.

I even did an attempt to make it look a little like MacOS,
by using freetype for the fonts and some bitmap buttons ?
But it wasn't finished, and I didn't need it in the end...

--anders
Oct 23 2006
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Bill Baxter wrote:


 Do they all support OpenGL 2.0?  Looks like Derelict 
 does now. 


I think that Derelict and Jamie Pelcis bindings* do now.
(* see D.announce/2982, but summerseas.com seems gone ?)

The DedicateD bindings used Microsofts GL 1.1 (I think)
and for my updated version I used SGI's SI: OpenGL 1.2
So you would have to use GL's extension mechanisms, to
use the newer features with those older import modules.

(DedicateD is still at http://int19h.tamb.ru/files.html)

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

Then again OpenGL 1.x is working just fine for "gears" :-)
And most people seem to prefer the Derelict loaders, so.

--anders
Oct 23 2006
next sibling parent reply James Pelcis <jpelcis gmail.com> writes:
Anders F Björklund wrote:

 I think that Derelict and Jamie Pelcis bindings* do now.
 (* see D.announce/2982, but summerseas.com seems gone ?)


Yes, they both support OpenGL 2.0.

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.

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.
Oct 23 2006
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Oct 24 2006
parent reply James Pelcis <jpelcis gmail.com> writes:
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.
Oct 24 2006
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Oct 25 2006
parent reply James Pelcis <jpelcis gmail.com> writes:
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?
Oct 25 2006
next sibling parent Paolo Invernizzi <arathorn NOSPAM_fastwebnet.it> writes:
James Pelcis wrote:


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


Whaaaaaaaaa! ;-P

---
Paolo
Oct 26 2006
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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/li
GL.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/li
GL.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
Oct 26 2006
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
 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
Oct 24 2006
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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
Oct 24 2006
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Oct 24 2006
prev sibling next sibling parent Mike Parker <aldacron71 yahoo.com> writes:
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 


DerelictGL is independent of DerelictSDL. You can use it with whatever 
library you like that creates the OpenGL context for you.
Oct 23 2006
prev sibling next sibling parent reply clayasaurus <clayasaurus gmail.com> writes:
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?


In defense of SDL...

1) Losing the OpenGL context on window resize only happens on Windows
2) Multi-window support in the future 
http://www.gamedev.net/community/forums/topic.asp?topic_id=380142


However, if you are going to make an standard OpenGL GUI, you should 
make it work with Win32, SDL, GLUT, GLFW, X, etc.
Oct 23 2006
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
clayasaurus wrote:

 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?


 
 In defense of SDL...
 
 1) Losing the OpenGL context on window resize only happens on Windows


Really?  GLUT supports resize without trashing the context on Windows. 
I wonder why SDL can't.  I thought I remembered the argument went 
something like "some platforms don't allow it, so we just trash the 
context on every platform to maintain consistent cross-platform 
behavior".  But if it only happens on Windows, then I don't get the 
reasoning...


 2) Multi-window support in the future 
 http://www.gamedev.net/community/forums/topic.asp?topic_id=380142


That'll be nice when it arrives, but according to Bob in the post below, 
it's been in the works since Fall of 2004, so I'm not holding my breath.
http://www.libsdl.org/pipermail/sdl/2005-July/069565.html


 However, if you are going to make an standard OpenGL GUI, you should 
 make it work with Win32, SDL, GLUT, GLFW, X, etc.


I think so too.  They all do about the same thing, so it would be nice 
to have them wrapped up in an abstract interface, even if only one of 
them is supported initially.

--bb
Oct 23 2006
prev sibling parent reply Bradley Smith <digitalmars-com baysmith.com> writes:
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
Nov 02 2006
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Nov 02 2006
parent Bradley Smith <digitalmars-com baysmith.com> writes:
 You know that the GLFW libary comes with bindings for D included, right?


Yes, I do. I've even contributed to the GLFW project in the form of 
patches and additional examples for the D bindings. However, the 
Derelict project has dropped its support of GLFW and were looking for a 
native D solution. I too wanted a native D solution.


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


Yes, it might, but that would depend upon someone else porting the MacOS 
X code.

   Bradley
Nov 02 2006