www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - OT: Started a blog about D, OpenGL and SDL

reply Olli Aalto <oaalto gmail.com> writes:
I wanted just to let you know that I started writing a blog about D, 
OpenGL and SDL. I will be doing mostly NeHe's tutorials, but I'll 
probably post about other things too. Mostly D and/or games.

So here it is http://odefu.blogspot.com/

There's not much yet, but I'll try to get the first lesson up later today.

O.
Jan 25 2007
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Olli Aalto wrote:

 I wanted just to let you know that I started writing a blog about D, 
 OpenGL and SDL. I will be doing mostly NeHe's tutorials, but I'll 
 probably post about other things too. Mostly D and/or games.
 
 So here it is http://odefu.blogspot.com/
Sounds good, be sure to use SDL_main if you want your programs to run on Mac OS X and not just Windows/Linux. extern(C) int SDL_main(int argc, char **argv) { ... } int main(char[][] args) { return SDL_InitApplication(args); } 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. --anders
Jan 25 2007
next sibling parent reply Olli Aalto <oaalto gmail.com> writes:
Anders F Björklund wrote:
 Olli Aalto wrote:
 
 I wanted just to let you know that I started writing a blog about D, 
 OpenGL and SDL. I will be doing mostly NeHe's tutorials, but I'll 
 probably post about other things too. Mostly D and/or games.

 So here it is http://odefu.blogspot.com/
Sounds good, be sure to use SDL_main if you want your programs to run on Mac OS X and not just Windows/Linux.
Yeah, I added a small disclaimer in my second post that I'm working on a Windows box mostly and wont try to make them completely cross platform, at least not yet. I do have a powerbook, but haven't gotten to try gdc on it yet. Hmm.. maybe this weekend when I'm going with my girlfriend to her parents. Need something to do, you know. :)
 extern(C)
 int SDL_main(int argc, char **argv)
 {
     ...
 }
 
 int main(char[][] args)
 {
     return SDL_InitApplication(args);
 }
 
 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.
 
Ok, good to know. O.
Jan 25 2007
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Olli Aalto wrote:

 Sounds good, be sure to use SDL_main if you want your
 programs to run on Mac OS X and not just Windows/Linux.
Yeah, I added a small disclaimer in my second post that I'm working on a Windows box mostly and wont try to make them completely cross platform, at least not yet. I do have a powerbook, but haven't gotten to try gdc on it yet. Hmm.. maybe this weekend when I'm going with my girlfriend to her parents. Need something to do, you know. :)
I'm updating my bindings for D 1.0, which seems to have broken them. But otherwise they are working good, but doesn't use Build/Derelict. SDL and OpenGL have been running OK on GDC/Mac since at least 2005. You can find the older on my page at http://www.algonet.se/~afb/d/ (I haved since moved opengl.gl over to gl.gl, and openal to al.al) --anders
Jan 25 2007
prev sibling parent reply Mike Parker <aldacron71 yahoo.com> writes:
Anders F Björklund wrote:
 
 Sounds good, be sure to use SDL_main if you want your
 programs to run on Mac OS X and not just Windows/Linux.
 
 extern(C)
 int SDL_main(int argc, char **argv)
 {
     ...
 }
 
 int main(char[][] args)
 {
     return SDL_InitApplication(args);
 }
 
 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.
 
 --anders
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!
Jan 25 2007
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Jan 25 2007
parent reply Carlos Santander <csantander619 gmail.com> writes:
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 work fine for me. -- Carlos Santander Bernal
Jan 26 2007
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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 

 seems to work fine for me.
Where do I put it ? I tried /etc/build.cfg, but that didn't work. --anders
Jan 26 2007
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Jan 26 2007
prev sibling parent reply Olli Aalto <oaalto gmail.com> writes:
Mike Parker wrote:
 Anders F Björklund wrote:
 Sounds good, be sure to use SDL_main if you want your
 programs to run on Mac OS X and not just Windows/Linux.

 extern(C)
 int SDL_main(int argc, char **argv)
 {
     ...
 }

 int main(char[][] args)
 {
     return SDL_InitApplication(args);
 }

 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.

 --anders
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!
By any chance do you know what needs to be done for derelict's SDL to work on a mac? I have one and I've probably got some time during the weekend, so I could give it a shot. I just need to know a little bit more of the problem. O.
Jan 25 2007
parent reply Mike Parker <aldacron71 yahoo.com> writes:
Olli Aalto wrote:
 Mike Parker wrote:
 By any chance do you know what needs to be done for derelict's SDL to 
 work on a mac? I have one and I've probably got some time during the 
 weekend, so I could give it a shot. I just need to know a little bit 
 more of the problem.
 
 O.
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. 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). 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. As you can see, it's a bit of an involved task :)
Jan 25 2007
next sibling parent Olli Aalto <oaalto gmail.com> writes:
Mike Parker wrote:
 Olli Aalto wrote:
 Mike Parker wrote:
 By any chance do you know what needs to be done for derelict's SDL to 
 work on a mac? I have one and I've probably got some time during the 
 weekend, so I could give it a shot. I just need to know a little bit 
 more of the problem.

 O.
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. 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). 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. As you can see, it's a bit of an involved task :)
Grrrrreeaat. =) I'll at least install gdc on my powerbook and play around, see if something useful comes of it. O.
Jan 26 2007
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Jan 26 2007
parent reply Mike Parker <aldacron71 yahoo.com> writes:
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.
Jan 26 2007
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Jan 26 2007
prev sibling parent Mike Parker <aldacron71 yahoo.com> writes:
Olli Aalto wrote:
 I wanted just to let you know that I started writing a blog about D, 
 OpenGL and SDL. I will be doing mostly NeHe's tutorials, but I'll 
 probably post about other things too. Mostly D and/or games.
 
 So here it is http://odefu.blogspot.com/
 
 There's not much yet, but I'll try to get the first lesson up later today.
 
 O.
Great news! The D blogosphere has been feeling lonely :)
Jan 25 2007