OT: Started a blog about D, OpenGL and SDL

[Anders F Björklund]

Mike Parker wrote:

> Apparently SDL_main does some sort of trickery that is a necessity, so 
> just loading in the SDL framework isn't enough to run an SDL app. 
> Whatever SDL_main is doing needs to be done by Derelict as well. I find 
> that rather poor design. IMO SDL_main should only be a convenience, not 
> a necessity, and any setup should be handled in SDL_Init. But, nothing I 
> can do about that.

It's an *awful* design, and GLUT does it the right way. Oh well.
(GLUT has a glutInit function you call at the start, much easier)

On Win32 and MacOS, SDL does a little trickery before the real main
by redefining "main" with a macro (!) that will call a SDL function:

/* The application's main() function must be called with C linkage,
    and should be declared like this:
#ifdef __cplusplus
extern "C"
#endif
         int main(int argc, char *argv[])
         {
         }
  */
#define main    SDL_main

/* The prototype for the application's main() function */
extern C_LINKAGE int SDL_main(int argc, char *argv[]);

This "SDL_main" does some SDL setup, and then calls the real "main"
with the arguments filtered (as some arguments are handled by SDL)

For Win32 you can fake this SDL_main by reproducing it in D, but
for the regular MacOS driver it is written in Objective-C (not C)...

It's possible to mix and match Phobos and Objective-C startup code
to get them to play nice, but it's much easier to just call their
code like they want to and is what I have been doing instead. i.e.
my D main calls a renamed SDL main, and then it calls my SDL_main:
http://www.algonet.se/~afb/d/SDLMain.patch
http://www.algonet.se/~afb/d/SDL_win32_main.patch

> Derelict should be playing nice with GDC. Anders submitted a patch a 
> while ago to make it do so. I suppose it's working, because the last 
> time someone tried to get Derelict up and running on the Mac they got 
> things compiling (then got bit by the SDL_main problem).

"dlopen" works on Mac OS X 10.4 (and has a compat version for 10.3)
so that should take care of the loading once the paths are entered.

I think the easiest way to "fix" SDL_main is to call it always, and
then take apart args to argc/argv only to assemble argc/argv to args.
But that requires the Windows/Linux code to be modified, and that's
about as politically hard as getting Walter to add Mac to D versions.

I have submitted some patches, but after a while you get tired of it
and just use GDC and SDL/GL instead of playing with DMD and Derelict.

http://www.algonet.se/~afb/d/lesson01.d.patch is the NeHe code patch.

> The only other concern is Bud. If Bud isn't working on the Mac, then 
> that means we'll need a Makefile system to build the Derelict libs. So a 
> priority of anyone getting working on Macifying Derelict should be to 
> get Bud functioning first.

Bud doesn't work right out of the box, but I hear it can be configed ?
For me it was mostly 1) objects in wrong directory 2) bad GDC suppport.

But I find both DMD and Bud confusing, since I'm used to GCC / GNU Make,
so it could just be something of a culture shock between Windows / Unix.

> As you can see, it's a bit of an involved task :)

Not really. It just haven't been a priority for either camp, I think.

--anders