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

Anders F Björklund escribió:
> Mike Parker wrote:
> 
>>> I don't think there is any support in Derelict for this,
>>> though. Or at least I haven't gotten it to work on a Mac.
>>
>> There will be, either as soon as I get me paws on a Mac or someone gets it implemented for me. The Mac market is a very important one for me. Higher conversion rates for indie games than on Windows!
> 
> Good to hear, I used to be a Mac game developer back in the day.
> 
> But I still haven't gotten Build or Derelict to work properly,
> and got tired of trying so I went back to the regular libraries
> and Make - at least that I know how to do, same as with C/C++.
> I'm sure Bud/DSSS/Derelict can be made to work, with some effort.
> 
> For now, I just posted the small change needed in the blog comments.
> 
> --anders

Have you tried the CFG file Gregor posted here http://www.dsource.org/forums/viewtopic.php?t=2156&start=15#12393 ? It seems to work fine for me.

-- 
Carlos Santander Bernal

Carlos Santander wrote:

>> I'm sure Bud/DSSS/Derelict can be made to work, with some effort.

> Have you tried the CFG file Gregor posted here http://www.dsource.org/forums/viewtopic.php?t=2156&start=15#12393 ? It seems to work fine for me.

Where do I put it ? I tried /etc/build.cfg, but that didn't work.

--anders

I wrote:

> Where do I put it ? I tried /etc/build.cfg, but that didn't work.

Never mind, copied the file to the Derelict folder which worked...

--anders

Anders F Björklund wrote:
> Mike Parker wrote:

> 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[]);

Exactly. I believe this was the original intent of SDL_main, but it got cluttered with other garbage as well.

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

For Win32, you can just skip it completely. I have a C framework I put together that uses SDL and doesn't even link in SDL_main. That's why DerelictSDL has no issues on Windows. All SDL_main does there is redirect stdout & stderr, call SDL_Init with the NO_PARACHUTE flag, and call ddhelp.exe for some reason, all of which can be done without.

I looked over the Mac version of SDL_main a while ago, but I didn't really grok it. What exactly does it do that is required to run an SDL app? Why can we not do without it on Mac? That's what I'm curious about.

Mike Parker wrote:

>> 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)...
> 
> For Win32, you can just skip it completely. I have a C framework I put together that uses SDL and doesn't even link in SDL_main. That's why DerelictSDL has no issues on Windows. All SDL_main does there is redirect stdout & stderr, call SDL_Init with the NO_PARACHUTE flag, and call ddhelp.exe for some reason, all of which can be done without.

I think it also accepts some parameters to change depth/driver/etc ?
Just figured if I'm doing a special main anyway, might use theirs...

> I looked over the Mac version of SDL_main a while ago, but I didn't really grok it. What exactly does it do that is required to run an SDL app? Why can we not do without it on Mac? That's what I'm curious about.

Well, on Mac OS X there are two major frameworks: Carbon and Cocoa.
(where Carbon is the old MacOS API, and Cocoa is the old NeXT API)

If you use Cocoa (which is SDL default), you need to initialize the
Objective-C runtime which is what SDLmain.m does. For Carbon I don't
think it does any special init you can't live without, similar to
the Win32 version of SDLmain... But there is a SDLmain there too.
(and if you use the X11 version of SDL it doesn't need any special
setup, similar to how it works on Linux. But that's not too common)

And while you could write a special D main replacement, to initialize
both Phobos/GC and Objective-C in the right order, I think that's
trickier than just calling the SDLmain after initializing D ? With
the added bonus of the stdout/stderr redirection and params, etc...
But the major reason why you can't live without SDLmain on Mac OS X
is that Obj-C/Cocoa runtime initialization done in the SDLmain.m.

Beyond setting up the runtime, it also loads and sets the menubar
from a NIB file. I think there's an alternate fancier SDLMain too.
You also need to link with /usr/lib/libobjc.dylib (or Cocoa.framework),
all this is normally done by using `sdl-config --libs` in the Makefile.

--anders