www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - SDL* and GL bindings

reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
My slightly ranty topic about the current state of SDL* and GL bindings.

Recently, some development in a program of mine made look for a new 
SDL+GL binding other than the one I was using. I was a bit dismayed 
about the current state of affairs, as I couldn't find a suitable 
binding. The existing bindings (that I know of) are D-Porting, Derelict 
and Anders's. The problems I found:

Dporting:
This was the version I was previously using (actually a modified version 
with module statements). The problem is that this binding is not 
actively developed (I think) and the creators are not accessible, at 
least not easily (the Japanese D community?). This became an issue 
because there is no documentation at all and I this I was unable to know 
how this binding dealt with the SDL_main hack. Similarly how could I 
suggest or discuss the implementation of proper module names?


Derelict:
I'm really not into Derelict's runtime lib loading. I think the 
advantages presented by this method (see at Static Import Issues at 
http://svn.dsource.org/projects/derelict/trunk/docs/index.html ) matter 
very little. The first issue can be solved by a one person, one time 
operation, who can then distribute the lib to other people. In fact, for 
dmd it amounts to "coffimplib <foobar.lib>", which hardly is a nuisance.

As for the second issue, c'mon, what more than displaying an error 
message can a program do when an /essential/ dll is not found? Indeed, 
how many games (or any application for that matter) do you know that 
have a different behavior when a dll is missing than the standard system 
error message?

Meanwhile, I believe that the disadvantages, such as Derelict being 
harder/longer to maintain/develop than a regular binding have much more 
impact. For instance Derelict currently *still* doesn't support MacOS. 
(Not that I use (or even like) Macs, but it's quite an important 
platform that should be supported)

This seems a shame to me, since Derelict is clearly the binding with the 
most commitment, exposure, and work done on it.

Anders's:
I assume the latest bindings are those of http://www.algonet.se/~afb/d/ 
am I right?
How does one work with the bindings? I don't know if they are supposed 
to be compiled, or just imported header-style, as no doc/readme explains 
it. And in any way:
- Compilation fails (at least the easy way) because of the mismatched 
module names. What's up with that? Why do only sdl.main and sdl.sdl have 
module statements?
- Importing as headers should work if one doesn't use 
SDL_InitApplication, or so I thought, but it still fails because of a 
missing:
   Error 42: Symbol Undefined __init_6events9SDL_Event
caused by the "wchar unicode" of "SDL_keysym" which has a non-zero init. 
Of course, it took me a while to figure this all out.

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
May 20 2006
next sibling parent reply Ant <duitoolkit yahoo.ca> writes:
Bruno Medeiros wrote:

 My slightly ranty topic about the current state of SDL* and GL bindings.



should I post a reply? should I?

no, better not...

Ant
May 20 2006
parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Ant wrote:

 Bruno Medeiros wrote:

 My slightly ranty topic about the current state of SDL* and GL bindings.


 
 
 should I post a reply? should I?
 
 no, better not...
 
 Ant


Huh...?
Did I post something wrong or inappropriate?

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
May 21 2006
parent James Dunne <james.jdunne gmail.com> writes:
Bruno Medeiros wrote:

 Ant wrote:
 

 Bruno Medeiros wrote:


 My slightly ranty topic about the current state of SDL* and GL bindings.




 should I post a reply? should I?

 no, better not...

 Ant


 
 
 Huh...?
 Did I post something wrong or inappropriate?
 


I don't get it either...

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/MU/S d-pu s:+ a-->? C++++$ UL+++ P--- L+++ !E W-- N++ o? K? w--- O 
M--  V? PS PE Y+ PGP- t+ 5 X+ !R tv-->!tv b- DI++(+) D++ G e++>e 
h>--->++ r+++ y+++
------END GEEK CODE BLOCK------

James Dunne
May 22 2006
prev sibling next sibling parent reply Mike Parker <aldacron71 yahoo.com> writes:
Bruno Medeiros wrote:


 
 Derelict:
 I'm really not into Derelict's runtime lib loading. I think the 
 advantages presented by this method (see at Static Import Issues at 
 http://svn.dsource.org/projects/derelict/trunk/docs/index.html ) matter 
 very little. The first issue can be solved by a one person, one time 
 operation, who can then distribute the lib to other people. In fact, for 
 dmd it amounts to "coffimplib <foobar.lib>", which hardly is a nuisance.


It's a nuisance to me. I started Derelict for my own use because I 
wasn't happy with the absence of runtime loading in existing bindings. I 
just happened to make it available for others to use as a small 
contribution to the D community. One man's trash is another man's 
treasure, as they say.



 
 As for the second issue, c'mon, what more than displaying an error 
 message can a program do when an /essential/ dll is not found? Indeed, 
 how many games (or any application for that matter) do you know that 
 have a different behavior when a dll is missing than the standard system 
 error message?
 


The problem is that when you consider the Windows environment, which is 
the platform most commercial games target, the average user is not all 
that tech savvy. A message that an application can't be launched because 
a DLL is missing is going to be meaningless to most people. The user 
will immediately blame the developer for releasing a 'faulty' program. 
The chain of consequences from that point on can go in any direction, 
with the best result being a tech support request and the worst being a 
lost sale or negative word of mouth. From a AAA, retail, boxed game 
perspective, no big deal. In the downloadable games space, it's a very 
big deal. Particularly for casual games developers. That's my primary 
area of interest.

Being able to control the type of error message displayed gives the 
developer the ability to provide more detailed information. Popping up a 
message box with instructions on how to solve the problem, or perhaps 
with the URL of a web page that contains such instructions, is much more 
user-friendly. It reduces the chance that the user will go ballistic and 
makes a much more professional presentation. That's the motivation 
behind that design decision. It's influenced by Windows, because that's 
my primary development environment. The Linux interface is the same for 
consistency.


 Meanwhile, I believe that the disadvantages, such as Derelict being 
 harder/longer to maintain/develop than a regular binding have much more 
 impact. For instance Derelict currently *still* doesn't support MacOS. 
 (Not that I use (or even like) Macs, but it's quite an important 
 platform that should be supported)
 
 This seems a shame to me, since Derelict is clearly the binding with the 
 most commitment, exposure, and work done on it.



Derelict really isn't difficult or time consuming to maintain. I just 
don't spend much time on it because I have a lot going on. From the 
beginning it's been a hobby. Derelict doesn't support Mac because I 
don't own a Mac. I would dearly love to get Mac support into the trunk. 
The only reason Linux is supported is because two of the maintainers 
(John & Tom) and other Derelict users (like Clay) regularly work on 
Linux. If not for them, Windows would be the only supported platform 
(I'm not a fan of Linux at all).

Anders is the only one who has ever contributed any Mac code to 
Derelict. If I could get someone on board who would be willing to 
maintain the Mac side of things, I would happily get Brad to grant them 
commit rights and let them at it. Until that day comes, there's nothing 
I can do about it. I'm not going to go out and buy a Mac just to add Mac 
support to a project I work on in my spare time.

Along the same vein, I'd also like to make the code base compatible with 
GDC on all three platforms. I can't be bothered to do it myself. So if 
anyone would be willing to maintain it, they are welcome to. That's the 
thing about open source projects. If there's something you see it needs, 
you can contribute it. Derelict is very much a community project. Many 
of the packages were contributed by users.

For what it's worth, one of the future additions to Derelict is going to 
be the ability to link statically with an import library and bypass the 
runtime loading mechanism. I prefer the runtime loading myself because 
of the flexibility it gives in runtime swapping of APIs (a lot of games 
use that technique - Unreal engine games, Quake engine games, the Age of 
Empires series, and others). But I do understand that, for whatever 
reason, it's a problem for some people (I still don't understand why - 
it's all done behind the scenes, there's no impact on performance, and 
it's highly flexible). I've already incorporated the ability into 
DerelictAL, though it hasn't been tested at all. To make use of it, just 
add the line 'version=DerelictAL_Static' to DerelictAL/forbuild.txt. 
Over the coming months I will add the same functionality to the other 
packages. No promises as to how long it will ultimately be, though.
May 20 2006
parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Mike Parker wrote:

 Bruno Medeiros wrote:
 

 Derelict:
 I'm really not into Derelict's runtime lib loading. I think the 
 advantages presented by this method (see at Static Import Issues at 
 http://svn.dsource.org/projects/derelict/trunk/docs/index.html ) 
 matter very little. The first issue can be solved by a one person, one 
 time operation, who can then distribute the lib to other people. In 
 fact, for dmd it amounts to "coffimplib <foobar.lib>", which hardly is 
 a nuisance.


 
 It's a nuisance to me. I started Derelict for my own use because I 
 wasn't happy with the absence of runtime loading in existing bindings. I 
 just happened to make it available for others to use as a small 
 contribution to the D community. One man's trash is another man's 
 treasure, as they say.
 
 


Yes, I understand it is a nuisance to you. But you wrote about the 
static linking disadvantages as if it were somewhat universally 
disadvantageous to anyone. :o (I just wanted to point it wasn't)


 As for the second issue, c'mon, what more than displaying an error 
 message can a program do when an /essential/ dll is not found? Indeed, 
 how many games (or any application for that matter) do you know that 
 have a different behavior when a dll is missing than the standard 
 system error message?


 
 The problem is that when you consider the Windows environment, which is 
 the platform most commercial games target, the average user is not all 
 that tech savvy. A message that an application can't be launched because 
 a DLL is missing is going to be meaningless to most people. The user 
 will immediately blame the developer for releasing a 'faulty' program. 
 The chain of consequences from that point on can go in any direction, 
 with the best result being a tech support request and the worst being a 
 lost sale or negative word of mouth. From a AAA, retail, boxed game 
 perspective, no big deal. In the downloadable games space, it's a very 
 big deal. Particularly for casual games developers. That's my primary 
 area of interest.
 
 Being able to control the type of error message displayed gives the 
 developer the ability to provide more detailed information. Popping up a 
 message box with instructions on how to solve the problem, or perhaps 
 with the URL of a web page that contains such instructions, is much more 
 user-friendly. It reduces the chance that the user will go ballistic and 
 makes a much more professional presentation. That's the motivation 
 behind that design decision. It's influenced by Windows, because that's 
 my primary development environment. The Linux interface is the same for 
 consistency.
 


But since dll's are usually packaged with the game/app itself, isn't a 
missing dll something so rare that it is exaggerated to worry about it 
so much? How can it happen at all, it seems so far-fetched.


 Meanwhile, I believe that the disadvantages, such as Derelict being 
 harder/longer to maintain/develop than a regular binding have much 
 more impact. For instance Derelict currently *still* doesn't support 
 MacOS. (Not that I use (or even like) Macs, but it's quite an 
 important platform that should be supported)

 This seems a shame to me, since Derelict is clearly the binding with 
 the most commitment, exposure, and work done on it.


 
 
 Derelict really isn't difficult or time consuming to maintain. I just 


It's more work than a pure static-link binding, no?


 don't spend much time on it because I have a lot going on. From the 
 beginning it's been a hobby. Derelict doesn't support Mac because I 
 don't own a Mac. I would dearly love to get Mac support into the trunk. 
 The only reason Linux is supported is because two of the maintainers 


Wouldn't a pure header conversion work in all platforms that the 
original header works in?...
It doesn't work on Mac, and it didn't work before in Linux because you 
need to add the code to the dynamic binding, right?

(Note: I'm not demanding or asking that you should work on static-link 
binding, as I'm fully aware this is your hobby project and you do 
whatever you want with it. I'm (mostly) just giving my take on the 
static vs. dynamic binding issue.)


 
 For what it's worth, one of the future additions to Derelict is going to 
 be the ability to link statically with an import library and bypass the 
 runtime loading mechanism. 


That would be great!

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
May 21 2006
next sibling parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Bruno Medeiros wrote:

 Mike Parker wrote:

 Bruno Medeiros wrote:


 Derelict:
 I'm really not into Derelict's runtime lib loading. I think the
 advantages presented by this method (see at Static Import Issues at
 http://svn.dsource.org/projects/derelict/trunk/docs/index.html )
 matter very little. The first issue can be solved by a one person,
 one time operation, who can then distribute the lib to other people.
 In fact, for dmd it amounts to "coffimplib <foobar.lib>", which
 hardly is a nuisance.


 It's a nuisance to me. I started Derelict for my own use because I
 wasn't happy with the absence of runtime loading in existing bindings.
 I just happened to make it available for others to use as a small
 contribution to the D community. One man's trash is another man's
 treasure, as they say.


 
 Yes, I understand it is a nuisance to you. But you wrote about the
 static linking disadvantages as if it were somewhat universally
 disadvantageous to anyone. :o (I just wanted to point it wasn't)
 

 As for the second issue, c'mon, what more than displaying an error
 message can a program do when an /essential/ dll is not found?
 Indeed, how many games (or any application for that matter) do you
 know that have a different behavior when a dll is missing than the
 standard system error message?


 The problem is that when you consider the Windows environment, which
 is the platform most commercial games target, the average user is not
 all that tech savvy. A message that an application can't be launched
 because a DLL is missing is going to be meaningless to most people.
 The user will immediately blame the developer for releasing a 'faulty'
 program. The chain of consequences from that point on can go in any
 direction, with the best result being a tech support request and the
 worst being a lost sale or negative word of mouth. From a AAA, retail,
 boxed game perspective, no big deal. In the downloadable games space,
 it's a very big deal. Particularly for casual games developers. That's
 my primary area of interest.

 Being able to control the type of error message displayed gives the
 developer the ability to provide more detailed information. Popping up
 a message box with instructions on how to solve the problem, or
 perhaps with the URL of a web page that contains such instructions, is
 much more user-friendly. It reduces the chance that the user will go
 ballistic and makes a much more professional presentation. That's the
 motivation behind that design decision. It's influenced by Windows,
 because that's my primary development environment. The Linux interface
 is the same for consistency.


 
 But since dll's are usually packaged with the game/app itself, isn't a
 missing dll something so rare that it is exaggerated to worry about it
 so much? How can it happen at all, it seems so far-fetched.


I can't think of any games that would ship with OpenGL.  The last time I
saw an opengl.dll file in a game, it was an OpenGL wrapper around Glide.

Aah, 3dfx... those were the days :P


 

 Meanwhile, I believe that the disadvantages, such as Derelict being
 harder/longer to maintain/develop than a regular binding have much
 more impact. For instance Derelict currently *still* doesn't support
 MacOS. (Not that I use (or even like) Macs, but it's quite an
 important platform that should be supported)

 This seems a shame to me, since Derelict is clearly the binding with
 the most commitment, exposure, and work done on it.



 Derelict really isn't difficult or time consuming to maintain. I just 


 
 It's more work than a pure static-link binding, no?


Having worked on dynamic-loading cairo bindings, I can say: yes but
kinda not really (see below).


 

 don't spend much time on it because I have a lot going on. From the
 beginning it's been a hobby. Derelict doesn't support Mac because I
 don't own a Mac. I would dearly love to get Mac support into the
 trunk. The only reason Linux is supported is because two of the
 maintainers 


 
 Wouldn't a pure header conversion work in all platforms that the
 original header works in?...
 It doesn't work on Mac, and it didn't work before in Linux because you
 need to add the code to the dynamic binding, right?


As I understand it, those .LIB files you get are basically (guess what)
dynamically loading the DLL.  It's just that they're generated by the
compiler or somesuch.  So what derelict is doing is exactly what those
static .LIB files are doing... except that it throws exceptions instead
of hurling a

	"Gaargh!  You system is b0rked!  Run aways!"

dialog at the user's face.  I'd personally much rather be able to show
them a

        "You don't appear to have OpenGL 2.0 installed.  Please check
         to make sure you are using the latest drivers for your graphics
         card.  If problems persist, feel free to drop us a line."

message.

In the end, I think it's six of one, a half-dozen of the other.  In the
end, the program runs exactly the same; the only differences are very
minor, and only happen on program start up.

As for the maintenance, I can't talk about how it's done in Derelict,
but with my binding I just have a small script that spits out all the
dynamic loading code for me.  All I have to do is take the C header
file, and rename a few types to the D equivalent.  What's more, that's
basically a one-off.  Once it's done, it's done.

Regarding supported platforms: the main stumbling block, at this point,
seems to be std.loader.  It's got some funny license on it that no one
seems comfortable with, but as yet it hasn't been replaced (correct me
if I'm wrong).  Mac OSX is most certainly capable of dynamically loading
libraries, so it's simply a matter of writing that code for Mac OSX.

At the end of the day, I'll continue writing my bindings using dynamic
loading, since I feel that it's the most flexible approach, and gives
programmers the most control over the process.

As a quick example, the upcoming Cairo 1.2 will add several new
features.  I plan on having a simple mechanism to allow programmers to
say "only load the features from Cairo 1.0", so that they don't get
errors if they try to use a 1.0 DLL with the latest version of the binding.

And you can't do that with a static .LIB :)

	-- Daniel Keep

P.S.  Sorry if this is a bit rambly.  Have MMX assembler on the brain at
the moment...


 
 (Note: I'm not demanding or asking that you should work on static-link
 binding, as I'm fully aware this is your hobby project and you do
 whatever you want with it. I'm (mostly) just giving my take on the
 static vs. dynamic binding issue.)
 

 For what it's worth, one of the future additions to Derelict is going
 to be the ability to link statically with an import library and bypass
 the runtime loading mechanism. 


 
 That would be great!
 


-- 

v1sw5+8Yhw5ln4+5pr6OFma8u6+7Lw4Tm6+7l6+7D
a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP    http://hackerkey.com/
May 21 2006
prev sibling parent reply Mike Parker <aldacron71 yahoo.com> writes:
Bruno Medeiros wrote:


 
 But since dll's are usually packaged with the game/app itself, isn't a 
 missing dll something so rare that it is exaggerated to worry about it 
 so much? How can it happen at all, it seems so far-fetched.


That's true for things like SDL and such, but not OpenGL. Sometimes 
downloads become corrupted, installations get borked, people delete 
files by accident... there are a lot of variables.

When Herb Marselas was still with Ensemble Studios he wrote an article 
for Game Programming Gems 2 called "Protect Yourself From DLL Hell and 
Missing OS Functions" in which he advocated even loading Win32 API DLLs 
manually. I'm not sure I'd go that far, as there are other applications 
that would likely barf before a game would. But his reasoning in the 
article was sound.

In my own experience, I have gotten the missing DLL message more than 
once, from games and other applications, over the years. As absurd as it 
sounds, it happens. When your target market is not as computer literate 
as the hardcore types, it's best to make it as easy on the user as possible.



 Derelict really isn't difficult or time consuming to maintain. I just 


 
 It's more work than a pure static-link binding, no?


Not much. The only extra work is declaring the function pointers and 
implementing the load functions. That's just a matter of copy and paste. 
  Or for the more industrious, implementing a script to handle it for you.



 
 Wouldn't a pure header conversion work in all platforms that the 
 original header works in?...
 It doesn't work on Mac, and it didn't work before in Linux because you 
 need to add the code to the dynamic binding, right?


Right. But then that would defeat the purpose of Derelict. Again, the 
other bindings already link to the import library statically. Derelict 
is meant to provide an alternative.


 

 For what it's worth, one of the future additions to Derelict is going 
 to be the ability to link statically with an import library and bypass 
 the runtime loading mechanism. 


 
 That would be great!


I'm glad you think so, but I still don't understand why. I flip-flopped 
on this for a long time, because it means double the effort and I just 
don't see the benefit of it versus the current mechanism. Manual loading 
is much more flexible, which to me equates to "better". I can't see any 
benefit at all to linking statically to the import libraries, other than 
the fact that you don't have to call a load method as the OS will handle 
that for you. Still, I have gotten messages from a few people who really 
see it differently. If adding the feature makes it more convenient for 
people, then I don't mind, even if I don't understand.
May 21 2006
parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Mike Parker wrote:

 Bruno Medeiros wrote:
 

 But since dll's are usually packaged with the game/app itself, isn't a 
 missing dll something so rare that it is exaggerated to worry about it 
 so much? How can it happen at all, it seems so far-fetched.


 
 That's true for things like SDL and such, but not OpenGL. Sometimes 
 downloads become corrupted, installations get borked, people delete 
 files by accident... there are a lot of variables.
 
 When Herb Marselas was still with Ensemble Studios he wrote an article 
 for Game Programming Gems 2 called "Protect Yourself From DLL Hell and 
 Missing OS Functions" in which he advocated even loading Win32 API DLLs 
 manually. I'm not sure I'd go that far, as there are other applications 
 that would likely barf before a game would. But his reasoning in the 
 article was sound.
 


The only time I can recall that an app unexpectedly didn't load a dll, 
was for some of the MSVC runtime libs. So following your reasoning, you 
should load these libs dynamically too.. *g* :P


 

 Wouldn't a pure header conversion work in all platforms that the 
 original header works in?...
 It doesn't work on Mac, and it didn't work before in Linux because you 
 need to add the code to the dynamic binding, right?


 
 Right. But then that would defeat the purpose of Derelict. Again, the 
 other bindings already link to the import library statically. Derelict 
 is meant to provide an alternative.
 

 For what it's worth, one of the future additions to Derelict is going 
 to be the ability to link statically with an import library and 
 bypass the runtime loading mechanism. 


 That would be great!


 
 I'm glad you think so, but I still don't understand why. I flip-flopped 
 on this for a long time, because it means double the effort and I just 
 don't see the benefit of it versus the current mechanism. Manual loading 
 is much more flexible, which to me equates to "better". I can't see any 
 benefit at all to linking statically to the import libraries, other than 


Well, if dynamic loading supports all platforms that static loading, 
then there really isn't much difference. But as we know, that is not the 
case. ;p


-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
May 22 2006
parent reply Mike Parker <aldacron71 yahoo.com> writes:
Bruno Medeiros wrote:

 Mike Parker wrote:



 
 Well, if dynamic loading supports all platforms that static loading, 
 then there really isn't much difference. But as we know, that is not the 
 case. ;p


Ah, not true. Dynamic loading is possible on all the platforms that D 
currently has been ported to. Derelict just doesn't support them all yet ;).
May 22 2006
parent Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Mike Parker wrote:

 Bruno Medeiros wrote:

 Mike Parker wrote:


 

 Well, if dynamic loading supports all platforms that static loading, 
 then there really isn't much difference. But as we know, that is not 
 the case. ;p


 
 Ah, not true. Dynamic loading is possible on all the platforms that D 
 currently has been ported to. Derelict just doesn't support them all yet 
 ;).


Yes, I know. That "if" was a "when" kind of "if" :P

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


 Anders's:
 I assume the latest bindings are those of http://www.algonet.se/~afb/d/ 
 am I right?


Yeah, although not in the zip files but *only* in the cvs section.

But I just updated the old versions that were provided by DedicateD,
and are also available from Japan: http://shinh.skr.jp/d/porting.html

A recent post included more modern/open source versions of the headers,
built from Mesa OpenGL and FreeGLUT instead of "my" SGI OpenGL and GLUT.

http://www.digitalmars.com/d/archives/digitalmars/D/announce/2982.html


 How does one work with the bindings? I don't know if they are supposed 
 to be compiled, or just imported header-style, as no doc/readme explains 
 it.


The makefiles and sample projects are all in the CVS for now, sorry.

Basically I just include everything in sdl/*.d and link it with SDL ?
(similar to how you use it from C, so it's wasn't very documented no)


 And in any way:
 - Compilation fails (at least the easy way) because of the mismatched 
 module names. What's up with that? Why do only sdl.main and sdl.sdl have 
 module statements?


The other ones just had implicit names, since they're all in "sdl"...


 - Importing as headers should work if one doesn't use 
 SDL_InitApplication, or so I thought, but it still fails because of a 
 missing:
   Error 42: Symbol Undefined __init_6events9SDL_Event
 caused by the "wchar unicode" of "SDL_keysym" which has a non-zero init. 
 Of course, it took me a while to figure this all out.


It should work with the mentioned Makefile, which builds a D library
(some of the SDL import modules do generate code, it's inevitable)

But when I said that I should really, really package it up better -
this is what I meant. It works for me, but I haven't documented it.


Once I update the headers to SDL 1.2.10 (etc), I will package it up too.
It will probably only work with GDC, but Derelict is good for DMD use ?

I also promised to write a tutorial for it, similar to the ones at:
http://dmedia.dprogramming.com/Main/Tutorials

--anders
May 21 2006
parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Anders F Björklund wrote:

 Bruno Medeiros wrote:
 

 Anders's:
 I assume the latest bindings are those of 
 http://www.algonet.se/~afb/d/ am I right?


 
 Yeah, although not in the zip files but *only* in the cvs section.
 


Ah, hadn't noticed that.


 But I just updated the old versions that were provided by DedicateD,
 and are also available from Japan: http://shinh.skr.jp/d/porting.html
 


Huh? I don't understand what you mean here. Where your bindings also 
based on DedicateD? What what does that have to do with the D-Porting 
bindings and why did you mention it?


 A recent post included more modern/open source versions of the headers,
 built from Mesa OpenGL and FreeGLUT instead of "my" SGI OpenGL and GLUT.
 
 http://www.digitalmars.com/d/archives/digitalmars/D/announce/2982.html
 


*Sigh*, yes, another binding to the mix. Like you said it seems similar 
to Derelict, except it is based on different GL headers?
I (currently) don't know enough about OpenGL to know the differences 
(and thus the advantages) between those newer/older opengl headers, so I 
don't know how more useful that binding would be over Derelict. (Meaning 
I'd rather use Derelict over that one)


 How does one work with the bindings? I don't know if they are supposed 
 to be compiled, or just imported header-style, as no doc/readme 
 explains it.


 
 The makefiles and sample projects are all in the CVS for now, sorry.
 
 Basically I just include everything in sdl/*.d and link it with SDL ?
 (similar to how you use it from C, so it's wasn't very documented no)
 


No, you *also* have to link with the SDL_D libs, right? (This is 
something that must be mentioned.)


 And in any way:
 - Compilation fails (at least the easy way) because of the mismatched 
 module names. What's up with that? Why do only sdl.main and sdl.sdl 
 have module statements?


 
 The other ones just had implicit names, since they're all in "sdl"...
 


I know they have implicit names, I can see that myself :P
But it is still broke. It works *only* if you compile each module 
separately, *and* if you only import sdl.sdl (or sdl.main) in your 
application. (if you import certain other sdl modules it breaks)
Surely you agree this is not proper behavior.?


 - Importing as headers should work if one doesn't use 
 SDL_InitApplication, or so I thought, but it still fails because of a 
 missing:
   Error 42: Symbol Undefined __init_6events9SDL_Event
 caused by the "wchar unicode" of "SDL_keysym" which has a non-zero 
 init. Of course, it took me a while to figure this all out.


 
 It should work with the mentioned Makefile, which builds a D library
 (some of the SDL import modules do generate code, it's inevitable)
 
 But when I said that I should really, really package it up better -
 this is what I meant. It works for me, but I haven't documented it.
 
 


The doc needed for this kind of stuff isn't much, just a couple 
paragraphs on a README file, I think.


 Once I update the headers to SDL 1.2.10 (etc), I will package it up too.
 It will probably only work with GDC, but Derelict is good for DMD use ?
 


Whoa! "will probably only work with GDC" !?  :|
(And MikeP also mentioned that Derelict didn't work with GDC as of yet) 
Are GDC and DMD so far off from each other that it is hard to build code 
that works in both?! What kind of things are working differently? (I 
only know of 'the lack of newer D features', and 'the typeof ==/is 
problem', both of which don't seem very problematic to the creation of 
bindings.)


 I also promised to write a tutorial for it, similar to the ones at:
 http://dmedia.dprogramming.com/Main/Tutorials
 
 --anders



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


 But I just updated the old versions that were provided by DedicateD,
 and are also available from Japan: http://shinh.skr.jp/d/porting.html


 
 Huh? I don't understand what you mean here. Where your bindings also 
 based on DedicateD? What what does that have to do with the D-Porting 
 bindings and why did you mention it?


AFAIK (my japanese isn't too good), those japanese ports are based on 
the versions from DedicateD (http://int19h.tamb.ru/files.html) and they 
are based on the same "idea" that the ones I did - i.e. just port them.

I just started mine over from "scratch" (i.e. the original C headers)
both for copyright and for updating reasons. The end results is very
similar though, and they are both in the "opengl" and "sdl" modules.

So I think all of these should all be source-compatible, for instance ?


 A recent post included more modern/open source versions of the headers,
 built from Mesa OpenGL and FreeGLUT instead of "my" SGI OpenGL and GLUT.

 http://www.digitalmars.com/d/archives/digitalmars/D/announce/2982.html


 
 *Sigh*, yes, another binding to the mix. Like you said it seems similar 
 to Derelict, except it is based on different GL headers?


It's similar to the ones above, in that is based on a port of C headers.
(seems to include more headers though, including the "platform" GL ones)

Derelict is based on a different idea, namely loading function pointers?


 I (currently) don't know enough about OpenGL to know the differences 
 (and thus the advantages) between those newer/older opengl headers, so I 
 don't know how more useful that binding would be over Derelict. (Meaning 
 I'd rather use Derelict over that one)


I think you understood the difference just fine, with your posting...
(they differ in automatization, and how they link to the libraries)


 Basically I just include everything in sdl/*.d and link it with SDL ?
 (similar to how you use it from C, so it's wasn't very documented no)


 
 No, you *also* have to link with the SDL_D libs, right? (This is 
 something that must be mentioned.)


The only tricky part is that Mac OS X can't use the regular SDLmain, but 
must use a SDLmain_d that has been patched to use a different "main" 
name so that the D and the Objective-C startup can co-exist nicely...

The other libraries are just a convenience that I used so that I didn't 
have to include all the of the source code files with every compilation.
But you *can* do that just fine, with the regular DMD syntax: gdmd *.d

(well, at least that was the idea - maybe it was messed up in practice)


 The other ones just had implicit names, since they're all in "sdl"...


 
 I know they have implicit names, I can see that myself :P
 But it is still broke. It works *only* if you compile each module 
 separately, *and* if you only import sdl.sdl (or sdl.main) in your 
 application. (if you import certain other sdl modules it breaks)
 Surely you agree this is not proper behavior.?


I do, but it worked for me when I put it in my /usr/include/d/sdl...
But I'll add the module names at the top of each file, to "fix" it.


 Once I update the headers to SDL 1.2.10 (etc), I will package it up too.
 It will probably only work with GDC, but Derelict is good for DMD use ?


 Whoa! "will probably only work with GDC" !?  :|
 (And MikeP also mentioned that Derelict didn't work with GDC as of yet) 


My main target is GDC and Make. I know that others prefer DMD and Build, 
  which is why I suggest that other libraries might be better if you do ?

In theory all the platforms belongs the same "GNU" target interface...
But I usually test my releases on Mac OS X, Windows XP and Fedora Core.


 Are GDC and DMD so far off from each other that it is hard to build code 
 that works in both?! What kind of things are working differently? (I 
 only know of 'the lack of newer D features', and 'the typeof ==/is 
 problem', both of which don't seem very problematic to the creation of 
 bindings.)


In my case, I just can't ever seem to get the standard (GCC) libraries 
working with the special (DMC) libraries with for instance OpenGL etc. ?

There are no real source changes, beyond that DMD uses "linux" and GDC 
uses "Unix" and that GDC is of an older DMD (language) specification.

--anders
May 21 2006
parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Anders F Björklund wrote:

 Bruno Medeiros wrote:

 A recent post included more modern/open source versions of the headers,
 built from Mesa OpenGL and FreeGLUT instead of "my" SGI OpenGL and GLUT.

 http://www.digitalmars.com/d/archives/digitalmars/D/announce/2982.html


 *Sigh*, yes, another binding to the mix. Like you said it seems 
 similar to Derelict, except it is based on different GL headers?


 
 It's similar to the ones above, in that is based on a port of C headers.
 (seems to include more headers though, including the "platform" GL ones)
 
 Derelict is based on a different idea, namely loading function pointers?
 


Huh? Jamie Pelcis bindings are similar to Derelict, since they also load 
function pointers. You said it yourself.


 Basically I just include everything in sdl/*.d and link it with SDL ?
 (similar to how you use it from C, so it's wasn't very documented no)


 No, you *also* have to link with the SDL_D libs, right? (This is 
 something that must be mentioned.)


 
 The only tricky part is that Mac OS X can't use the regular SDLmain, but 
 must use a SDLmain_d that has been patched to use a different "main" 
 name so that the D and the Objective-C startup can co-exist nicely...
 
 The other libraries are just a convenience that I used so that I didn't 
 have to include all the of the source code files with every compilation.
 But you *can* do that just fine, with the regular DMD syntax: gdmd *.d
 
 (well, at least that was the idea - maybe it was messed up in practice)
 


gdmd? What's that about? Isn't it an old project?

In any case, you can't do "dmd *.d" on the bindings just fine (with dmd 
at least,haven't tried with gdc), as it fails the compilation because of 
the mismatched module names, which is what I'm trying to say.


 The other ones just had implicit names, since they're all in "sdl"...


 I know they have implicit names, I can see that myself :P
 But it is still broke. It works *only* if you compile each module 
 separately, *and* if you only import sdl.sdl (or sdl.main) in your 
 application. (if you import certain other sdl modules it breaks)
 Surely you agree this is not proper behavior.?


 
 I do, but it worked for me when I put it in my /usr/include/d/sdl...
 But I'll add the module names at the top of each file, to "fix" it.
 


Like I said, if I'm not mistaken, it only worked because you compiled 
each module separately, and because you imported only the sdl.sdl module 
(or sdl.main).
(And thanks for the upcoming fix.)


 Once I update the headers to SDL 1.2.10 (etc), I will package it up too.
 It will probably only work with GDC, but Derelict is good for DMD use ?


 Whoa! "will probably only work with GDC" !?  :|
 (And MikeP also mentioned that Derelict didn't work with GDC as of yet) 


 
 My main target is GDC and Make. I know that others prefer DMD and Build, 
  which is why I suggest that other libraries might be better if you do ?
 
 In theory all the platforms belongs the same "GNU" target interface...
 But I usually test my releases on Mac OS X, Windows XP and Fedora Core.
 

 Are GDC and DMD so far off from each other that it is hard to build 
 code that works in both?! What kind of things are working differently? 
 (I only know of 'the lack of newer D features', and 'the typeof ==/is 
 problem', both of which don't seem very problematic to the creation of 
 bindings.)


 
 In my case, I just can't ever seem to get the standard (GCC) libraries 
 working with the special (DMC) libraries with for instance OpenGL etc. ?
 
 There are no real source changes, beyond that DMD uses "linux" and GDC 
 uses "Unix" and that GDC is of an older DMD (language) specification.
 
 --anders


I'm not understanding you here. What special DMC libraries? What's the 
relation with OpenGL? (that phrase seems a bit misconstructed)

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


 Derelict is based on a different idea, namely loading function pointers?


 
 Huh? Jamie Pelcis bindings are similar to Derelict, since they also load 
 function pointers. You said it yourself.


Oops, I must have been confused. Either way, there are two schools :-)
And I'm not really into pointers, unless they are needed (GL extensions)


 gdmd? What's that about? Isn't it an old project?


"gdmd" is a shell/script wrapper that converts the DM-style syntax into 
the GNU-style syntax as "gdc" expects. It's not another project/compiler


 In any case, you can't do "dmd *.d" on the bindings just fine (with dmd 
 at least,haven't tried with gdc), as it fails the compilation because of 
 the mismatched module names, which is what I'm trying to say.


I know, I meant to write sdl/*.d. But I will rewrite it properly...
(it's not really as confusing as I am making it sound, fortunately)

We both agree on how it should be, no use rationalizing the old hacks.
Once I have something new out, then we can start this thread over. :-)


 In my case, I just can't ever seem to get the standard (GCC) libraries 
 working with the special (DMC) libraries with for instance OpenGL etc. ?

 There are no real source changes, beyond that DMD uses "linux" and GDC 
 uses "Unix" and that GDC is of an older DMD (language) specification.


 
 I'm not understanding you here. What special DMC libraries? What's the 
 relation with OpenGL? (that phrase seems a bit misconstructed)


They use different "lib" formats, which I believe is one of the major 
reasons why it is so hard to link with DLLs on Windows and why Derelict 
et al were born in the first place ? On Linux and Mac OS X, I can just 
link directly with the shared libraries - no import libraries required.

My problems with DMC was when I tried to link with OpenGL and wxWidgets,
and with the SDL libraries from the binary SDL distribution. They never 
seemed to work right out of the box, unless I rebuilt them from source.
Thus "special", it seems that any binaries are for a) VS or b) MinGW ?


For me coming from Unix, it's easier to just use MSYS: configure && make
But DMC/DMD and DM-Make/Build might be easier if you're used to Windows?

--anders
May 22 2006
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Anders F Björklund wrote:

 Bruno Medeiros wrote:
 [snip]
 
 They use different "lib" formats, which I believe is one of the major
 reasons why it is so hard to link with DLLs on Windows and why Derelict
 et al were born in the first place ? On Linux and Mac OS X, I can just
 link directly with the shared libraries - no import libraries required.
 
 My problems with DMC was when I tried to link with OpenGL and wxWidgets,
 and with the SDL libraries from the binary SDL distribution. They never
 seemed to work right out of the box, unless I rebuilt them from source.
 Thus "special", it seems that any binaries are for a) VS or b) MinGW ?
 


The thing is that ".LIB" can mean a few things:

1. An OMF static library,
2. A COFF static library,
3. A post VC6 (I believe) COFF static library,
4. A "Whatever the hell format MS decides to use this month" static library.

The problem is that MS kept changing what format static libraries were
in.  DMD uses the original OMF format, but this is problematic since
most binary distributions of libraries are compiled for the "latest"
static library format for MSVC, which as I said is not OMF.

In that case, you've got 2 options: try to convert the import library
back to OMF (which seems to work OK most of the time), or recompile.

This is why I prefer the pure-D dynamic loading approach: the problem
simply doesn't come up :)


 
 For me coming from Unix, it's easier to just use MSYS: configure && make
 But DMC/DMD and DM-Make/Build might be easier if you're used to Windows?


I believe you can change which compiler build uses in the configuration
files.  That said, I think the whole point of build was the remove the
need for autoconf and makefiles entirely.  I know that *I've* had my
share of pain from being forced to use the GNU toolchain under
Windows... any tool that makes that whole damn archaic mess obsolete is
gold in my book.


 
 --anders


	-- Daniel

-- 

v1sw5+8Yhw5ln4+5pr6OFma8u6+7Lw4Tm6+7l6+7D
a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP    http://hackerkey.com/
May 22 2006
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Daniel Keep wrote:


 The problem is that MS kept changing what format static libraries were
 in.  DMD uses the original OMF format, but this is problematic since
 most binary distributions of libraries are compiled for the "latest"
 static library format for MSVC, which as I said is not OMF.
 
 In that case, you've got 2 options: try to convert the import library
 back to OMF (which seems to work OK most of the time), or recompile.
 
 This is why I prefer the pure-D dynamic loading approach: the problem
 simply doesn't come up :)


I've found that using another operating systems also helps,
but am trying to learn the arcane skills of Win DLL linking.

I totally blame Microsoft and Visual Studio for all of it...


For me coming from Unix, it's easier to just use MSYS: configure && make
But DMC/DMD and DM-Make/Build might be easier if you're used to Windows?


 
 I believe you can change which compiler build uses in the configuration
 files.  That said, I think the whole point of build was the remove the
 need for autoconf and makefiles entirely.  I know that *I've* had my
 share of pain from being forced to use the GNU toolchain under
 Windows... any tool that makes that whole damn archaic mess obsolete is
 gold in my book.


Swapping one pain for another, hoping that it is less ? ;-)

I know that *I* have had my share of pain trying to compile
projects hardcoded to DMD and Build under Unix or Mac OS X...

--anders
May 22 2006
prev sibling parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Anders F Björklund wrote:

 Bruno Medeiros wrote:
 

 Derelict is based on a different idea, namely loading function pointers?


 Huh? Jamie Pelcis bindings are similar to Derelict, since they also 
 load function pointers. You said it yourself.


 
 Oops, I must have been confused. Either way, there are two schools :-)
 And I'm not really into pointers, unless they are needed (GL extensions)
 

 gdmd? What's that about? Isn't it an old project?


 
 "gdmd" is a shell/script wrapper that converts the DM-style syntax into 
 the GNU-style syntax as "gdc" expects. It's not another project/compiler
 


I was thinking gdmd was this (an old D compiler):
http://www.digitalmars.com/d/archives/D/gnu/462.html
Only now have I realized that this was GDC's previous name, right?



 In any case, you can't do "dmd *.d" on the bindings just fine (with 
 dmd at least,haven't tried with gdc), as it fails the compilation 
 because of the mismatched module names, which is what I'm trying to say.


 
 I know, I meant to write sdl/*.d. But I will rewrite it properly...
 (it's not really as confusing as I am making it sound, fortunately)
 


It is the same, with "sdl/*.d" it will still not compile due to module 
conflicts.


 We both agree on how it should be, no use rationalizing the old hacks.
 Once I have something new out, then we can start this thread over. :-)
 


Ok. ;)


 In my case, I just can't ever seem to get the standard (GCC) 
 libraries working with the special (DMC) libraries with for instance 
 OpenGL etc. ?

 There are no real source changes, beyond that DMD uses "linux" and 
 GDC uses "Unix" and that GDC is of an older DMD (language) 
 specification.


 I'm not understanding you here. What special DMC libraries? What's the 
 relation with OpenGL? (that phrase seems a bit misconstructed)


 
 They use different "lib" formats, which I believe is one of the major 
 reasons why it is so hard to link with DLLs on Windows and why Derelict 
 et al were born in the first place ? On Linux and Mac OS X, I can just 
 link directly with the shared libraries - no import libraries required.
 
 My problems with DMC was when I tried to link with OpenGL and wxWidgets,
 and with the SDL libraries from the binary SDL distribution. They never 
 seemed to work right out of the box, unless I rebuilt them from source.
 Thus "special", it seems that any binaries are for a) VS or b) MinGW ?
 


Yes, they use different "lib" formats, and to link successfully you have 
to rebuild the .lib with DMC from the sources, or, more easily, you now 
have the "coffimplib" tool that does that work:
http://www.digitalmars.com/d/archives/c++/announce/864.html

But what has this to do with the compatibility of the D bindings 
themselves? Seems to me it doesn't affect it at all.


 
 For me coming from Unix, it's easier to just use MSYS: configure && make
 But DMC/DMD and DM-Make/Build might be easier if you're used to Windows?
 
 --anders


I think Build is easier in *any* platform.
Also, I use Windows, but I have MSYS installed and use it often. In 
fact, in the semester that I had some C++ projects, I used mingw's GCC 
(plus Eclipse CDT) more often than MS VC++.
In any case this is all besides the point.

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


 Yes, they use different "lib" formats, and to link successfully you have 
 to rebuild the .lib with DMC from the sources, or, more easily, you now 
 have the "coffimplib" tool that does that work:
 http://www.digitalmars.com/d/archives/c++/announce/864.html


Yeah, it's probably just me but those tools just kept crashing...


 But what has this to do with the compatibility of the D bindings 
 themselves? Seems to me it doesn't affect it at all.


None, it's just that I could see how people want "function pointers"
on non-GNU Windows where linking to shared libraries can be a hassle.


 For me coming from Unix, it's easier to just use MSYS: configure && make
 But DMC/DMD and DM-Make/Build might be easier if you're used to Windows?


 
 I think Build is easier in *any* platform.


When it works, I had a hard time getting started with it on the Mac.


 Also, I use Windows, but I have MSYS installed and use it often. In 
 fact, in the semester that I had some C++ projects, I used mingw's GCC 
 (plus Eclipse CDT) more often than MS VC++.
 In any case this is all besides the point.


Indeed. :-) But I think I got both DMC and GCC sorted out, for wxD.
For things such as these SDL/GL headers, it should be a lot easier...

--anders
May 22 2006
parent Derek Parnell <derek psych.ward> writes:
On Mon, 22 May 2006 20:54:35 +0200, Anders F Björklund wrote:



 I think Build is easier in *any* platform.


 
 When it works, I had a hard time getting started with it on the Mac.


Lend me a Mac for a while and I'll get it running sweetly just for you. ;-)

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
23/05/2006 10:12:52 AM
May 22 2006
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 22 May 2006 18:41:41 +0100, Bruno Medeiros wrote:

 

 I think Build is easier in *any* platform.


The next release (any day now) will be a lot more platform friendly as most
platform-dependant stuff will be user configurable.

(P.S.  Documentation takes soooo looooong!)

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
23/05/2006 10:09:58 AM
May 22 2006
parent Brad Anderson <brad dsource.org> writes:
Derek Parnell wrote:

 (P.S.  Documentation takes soooo looooong!)


As I go through the Postgresql website as an example of solid documentation, I
can say that Build fans will love you for it!!

BA
May 22 2006
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Bruno Medeiros wrote:


 Meanwhile, I believe that the disadvantages, such as Derelict being 
 harder/longer to maintain/develop than a regular binding have much more 
 impact. For instance Derelict currently *still* doesn't support MacOS. 
 (Not that I use (or even like) Macs, but it's quite an important 
 platform that should be supported)


Derelict doesn't have any technical reasons for not running on Mac OS X, 
it's just lacking active users to help implement the needed sections...

I posted a few patches / items left to do, on the Derelict forum.
http://www.dsource.org/forums/viewforum.php?f=19

Basically add a few locations to where the libraries are located, and 
implement "AGL", "NSGL", and "CGL" for the platform OpenGL extensions ?

http://developer.apple.com/qa/qa2001/qa1269.html

The Mac issues were mostly about the needed environment, like setting up
"Build" (for build scripts) and "dlcompat" (for shared library loading)

--anders
May 21 2006