SDL* and GL bindings

[Daniel Keep]

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/