SDL* and GL bindings

[Mike Parker]

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.