FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Derelict on Mac OS X - another solution
Goto page 1, 2, 3, 4, 5, 6  Next
 
Post new topic   Reply to topic     Forum Index -> Derelict
View previous topic :: View next topic  
Author Message
Crispy



Joined: 26 Nov 2005
Posts: 67

PostPosted: Wed Nov 28, 2007 5:04 am    Post subject: Derelict on Mac OS X - another solution Reply with quote

I've ported my Derelict game to Mac OS X. It compiles, runs, renders via SDL+OpenGL, displays fonts via SDL_ttf, loads images via SDL_image, and plays sound via SDL_mixer. Still a few rough edges to sort out, but the bulk of the work is done. I thought I'd share the D code I used to get this working.

I hereby release this entire post, including all code samples, into the public domain, in the manner described in this document: http://creativecommons.org/licenses/publicdomain/

There are two problems with DerelictSDL on Mac OS X out-of-the-box:

PROBLEM: Derelict does not specify default .framework names/paths for many libraries. On one level this makes sense because these are the libraries that are not installed on all Mac OS X machines. But I think sensible defaults are desirable, and do exist.

SOLUTION: Here are my proposed framework search paths.

../Frameworks/LIBNAME.framework/LIBNAME
/Library/Frameworks/LIBNAME.framework/LIBNAME
/System/Library/Frameworks/LIBNAME.framework/LIBNAME

There may be other paths which should be added to this (~/Library maybe? anyone want to look up the Apple docs on this?) but this is a solid start.

The third of those I discovered myself (it's where the SDL framework packages from libsdl.org install themselves); the second is courtesy of proj, from this thread: http://www.dsource.org/forums/viewtopic.php?t=1528&start=15

The first is new. Here is the logic behind it:

1. The prebuilt SDL_*.framework packages available from libsdl.org link to ../Frameworks/SDL.framework, so it seems standard at least among that crowd

2. When using an app bundle to distribute your game, it's in what I believe is the correct place for a Frameworks folder within the bundle. (A bundle in Mac OS X is a specially-named folder with a certain internal folder structure that pretends to be an executable application. The Finder implements this illusion.)

You end up with this Apple-given structure in your application bundle:

MyGame.app
....Contents
........Resources (data files go here)
........MacOS (executable goes here)
........Frameworks (frameworks - which are bundles in themselves! - go in here)

So your executable is in MyGame.app/Contents/MacOS/, and it links to ../Frameworks/LIBNAME.framework/LIBNAME, which because of the folder structure resolves to MyGame.app/Contents/Frameworks/LIBNAME.framework/LIBNAME, which just happens to be the right place. Smile

-----

PROBLEM: A Derelict app built in Mac OS X that works on other OSes will print a bunch of errors and then quit. The errors mostly relate to there being no autorelease pool (NSAutoreleasePool class). There's also an error that's due to not calling NSApplicationLoad before using certain Cocoa functions.

SOLUTION: This has been solved before, but existing solutions rely on linking statically to SDLmain.m, the Objective-C hack that apparently messes with the main function in order to do the required Cocoa initialisation before the library user's app starts. I'm not comfortable with this; not for any technical reason, but because SDLmain.m's licencing status is unclear. The licence is not specified in the file. If it's LGPL like the rest of SDL, then statically linking with it is a no-no for a closed source game.

So I scrounged around for documentation and came up with my own solution.

Code:
void createAutoreleasePool();

private bool donePlatformInit = false;
void platformInit() {
   if (donePlatformInit) return;
   version(darwin) {
      void* cocoa_lib;
      cocoa_lib = dlopen( "/System/Library/Frameworks/Cocoa.framework/Cocoa", 0 );
      void (*nsappload)();
      nsappload = cast(void(*)()) dlsym( cocoa_lib, "NSApplicationLoad");
      nsappload();
      createAutoreleasePool();
   }
   donePlatformInit = true;
}


That's one half. The other is an Objective-C file, which I called cocoabits.m:

Code:
#import <Cocoa/Cocoa.h>
#import <Foundation/NSAutoreleasePool.h>

NSAutoreleasePool* globalPool;

void createAutoreleasePool() {
   globalPool = [[NSAutoreleasePool alloc] init];
}

void destroyAutoreleasePool() {
   [globalPool release];
}


Compile the above with gcc:

gcc -c cocoabits.m -o cocoabits.o

And link cocoabits.o in with your D program by specifying it on the command line to your build tool. (This works because gdc is based on gcc and shares the same object file format.)

Then no errors are thrown and everything works nicely.

Bugs:
- I'm not cleaning up the pool. At one point I was calling destroyAutoreleasePool() to release the pool, but this just caused a crash. This may be because you're supposed to release such a pool in the same scope as you created it (the Apple docs just say "you should" and don't say why that is). But I don't think it matters, since all memory is returned to the OS on exit anyway. Ergo, letting it "leak" is fine.

- I did try to wrap the main function like SDLmain.m apparently does, so that I could free the pool in the same scope as it was created, but couldn't get it to work - it crashed when calling into D code, possibly due to an incorrect calling convention or something. Didn't want to look at SDLmain.m to see how they're doing it because of licencing contamination concerns.

- I didn't call dlclose() on the handle, and I probably should have, provided doing so doesn't cause the Cocoa framework to be unloaded.

- It would be nice to do this in pure D. The D part above demonstrates how to call standalone Cocoa functions. I wasn't sure how to do the OO stuff via dlopen (though it should be possible with the right name mangling?) so I just left it as Obj-C code. This works fine. I've incorporated the cocoabits compile into my build process so it's no extra hassle for me.

-----

PROBLEM: I'm still getting a crash (actually a SIGILL - could it be an assert?) deep inside SDL, after there are many keystrokes pressed. (It seems to happen upon a keystroke.) I'm unsure if this is SDL's fault, or if there's something I still need to initialise.

I have a crash report with a backtrace somewhere, but not on me at the moment. If I remember I'll post it later.

-----

I hope this helps someone. It would be nice to get some kind of proper Mac OS X support into the Derelict trunk so library users don't have to bother with all this. Certainly the first point should be easy to do; it's a one-line change for each affected library.

The second point (all the code) may need a bit of work before it's considered good enough to be committed, I don't know. It certainly works but it's a little messy. Removing the Obj-C dependency would be nice, and sounds doable.

If something like this code is added, I suggest that it goes in DerelictSDL.load() somewhere. It needs to be called before SDL_Init() can ever be called, and it shouldn't be called if SDL is not required, so this seems like the obvious place.
Back to top
View user's profile Send private message
Crispy



Joined: 26 Nov 2005
Posts: 67

PostPosted: Fri Dec 07, 2007 1:06 am    Post subject: Reply with quote

Here's that stack trace I mentioned. (Apple's Crash Reporter rocks!) Any help with this would be grand. Free copy of the game to anyone who helps me track down the problem. Smile

Code:
PID:    4490
Thread: 0

Exception:  EXC_BREAKPOINT (0x0006)
Code[0]:    0x00000002
Code[1]:    0x00000000


Thread 0 Crashed:
0   com.apple.Foundation         0x9262b50b _NSRaiseError + 227
1   com.apple.Foundation         0x926522cb +[NSException raise:format:] + 57
2   com.apple.AppKit             0x932f0400 -[NSLayoutManager glyphRangeForTextContainer:] + 150
3   com.apple.AppKit             0x9370d644 -[NSTextView(NSKeyBindingCommands) _rangeForMoveDownFromRange:verticalDistance:desiredDistanceIntoContainer:selectionAffinity:] + 1260
4   com.apple.AppKit             0x9370b1ec -[NSTextView(NSKeyBindingCommands) _moveDown:] + 447
5   com.apple.AppKit             0x9336a249 -[NSResponder doCommandBySelector:] + 76
6   com.apple.AppKit             0x9336a0dc -[NSTextView doCommandBySelector:] + 229
7   com.apple.AppKit             0x9335f868 -[NSKeyBindingManager(NSKeyBindingManager_MultiClients) interpretEventAsCommand:forClient:] + 1932
8   com.apple.AppKit             0x9335ddc9 -[NSTSMInputContext interpretKeyEvents:] + 1157
9   com.apple.AppKit             0x9335d170 -[NSView interpretKeyEvents:] + 65
10  SDL                          0x300330ce SDL_SoftStretch + 7770
11  SDL                          0x30033cce SDL_SoftStretch + 10842
12  SDL                          0x30006dbe SDL_PollEvent + 92
13  MayhemIntergalactic          0x00009c85 _D3app6events12handleeventsFC3app11application11ApplicationZb + 357 (events.d:42)
14  MayhemIntergalactic          0x00006cea _D3app11application11Application8mainloopMFZb + 191 (application.d:374)
15  MayhemIntergalactic          0x000042c7 _Dmain + 5335 (main.d:172)
16  MayhemIntergalactic          0x000cdd26 _D9dgccmain211_d_run_mainUiPPaPUAAaZiZi2goMFZv + 61
17  MayhemIntergalactic          0x000cde18 _d_run_main + 160
18  MayhemIntergalactic          0x000ae442 main + 40
19  MayhemIntergalactic          0x000026de _start + 216
20  MayhemIntergalactic          0x00002605 start + 41

Thread 1:
0   libSystem.B.dylib            0x90009817 mach_msg_trap + 7
1   com.apple.CoreFoundation     0x9082b2f3 CFRunLoopRunSpecific + 2014
2   com.apple.CoreFoundation     0x9082ab0e CFRunLoopRunInMode + 61
3   com.apple.audio.CoreAudio    0x9146541e HALRunLoop::OwnThread(void*) + 158
4   com.apple.audio.CoreAudio    0x91465239 CAPThread::Entry(CAPThread*) + 93
5   libSystem.B.dylib            0x90023d67 _pthread_body + 84

Thread 2:
0   libSystem.B.dylib            0x90048a27 semaphore_timedwait_signal_trap + 7
1   com.apple.audio.CoreAudio    0x9147265c CAGuard::WaitFor(unsigned long long) + 212
2   com.apple.audio.CoreAudio    0x9147257e CAGuard::WaitUntil(unsigned long long) + 66
3   com.apple.audio.CoreAudio    0x91470efa HP_IOThread::WorkLoop() + 690
4   com.apple.audio.CoreAudio    0x91470c43 HP_IOThread::ThreadEntry(HP_IOThread*) + 17
5   com.apple.audio.CoreAudio    0x91465239 CAPThread::Entry(CAPThread*) + 93
6   libSystem.B.dylib            0x90023d67 _pthread_body + 84

Thread 0 crashed with X86 Thread State (32-bit):
  eax: 0x007da000    ebx: 0x9262b436 ecx: 0x90a63b30 edx: 0x01307670
  edi: 0x01317da0    esi: 0x013a6aa0 ebp: 0xbfffe6e8 esp: 0xbfffe680
   ss: 0x0000001f    efl: 0x00200246 eip: 0x9262b50b  cs: 0x00000017
   ds: 0x0000001f     es: 0x0000001f  fs: 0x00000000  gs: 0x00000037


Edit: I tried removing the -q -rdynamic flags as suggested elsewhere - no dice. Anyway, this is a very intermittent error - it can take 15 minutes or more of actively playing the game to reproduce it - and the -rdynamic thing seemed like it was a repeatable crash.
Back to top
View user's profile Send private message
aldacron



Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea

PostPosted: Fri Dec 07, 2007 7:56 am    Post subject: Reply with quote

Wish I could help. I suggest you get a copy of the game to Anders Bjorklund if he's willing to help fix it.
_________________
The One With D | The One With Aldacron | D Bits
Back to top
View user's profile Send private message Send e-mail
Crispy



Joined: 26 Nov 2005
Posts: 67

PostPosted: Sat Dec 08, 2007 5:17 am    Post subject: Reply with quote

Good idea. I'll ask him if it crops up again.

In the meantime, though, I seem to have fixed this by reverting from SDL 1.2.12 to SDL 1.2.10. That is to say, I haven't been able to reproduce it using SDL 1.2.10 - but of course that doesn't mean it's actually gone. Smile It's very intermittent, so it's possible that I was just lucky when testing. I did test it by actively playing the game many times over the course of half an hour, though, whereas it usually cropped up after two play sessions at the most; so I'm hopeful.

There were some keyboard handling changes in SDL 1.2.12, so it's plausible that this is an SDL 1.2.12 bug. I haven't found any other reports of a such a bug though. I guess we'll see.
Back to top
View user's profile Send private message
hugues



Joined: 09 Aug 2007
Posts: 20
Location: Brussels, Belgium

PostPosted: Thu Mar 27, 2008 3:40 pm    Post subject: SDL and OpenGL with Derelict on Mac OS X Reply with quote

I'm glad to see that I'm not the only one to have problems using SDL and OpenGL while developing in D on Mac OS X Smile.

I tried to run a simple SDL test program (without Derelict) that initializes SDL, opens a window and enters a main loop waiting for the application to quit. As you mentioned, I got a bunch of error messages concerning _NSAutoreleaseNoPool(). I wrote the same test program in C and noticed how SDL redefines the main() function as SDL_main() and the need to link with libSDLmain.a. In SDLmain.m, it initializes an NSApplication an calls user's main() (redefined as SDL_main()) from inside its main loop. It looks like an ugly hack to me, because it redefines the main() function (which works in C with a #define but is not easily adaptable to other languages) and because it needs to link to another library than just SDL.

I could still run my test program in D by renaming my main() to SDL_main() and linking with libSDLmain.a, but there seems to be a problem concerning memory allocation. Just calling std.string.toStringz() was crashing the program like this:

Code:
Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000000

Thread 0 Crashed:
0   sdltest                     0x0000c425 _d_newarrayiT + 116
1   sdltest                     0x0000612a _D3std6string9toStringzFAaZPa + 72
2   sdltest                     0x00002a7b SDL_main + 411
...


I was wondering about how to get rid of SDLmain.m and couldn't find an answer before finding your post. I didn't try your solution yet, but I'm confident knowing you succeeded to port your game.

Regarding SDLmain.m licensing, I found this post where Sam Lantinga writes:
Quote:
In fact, if you look at the SDLmain source files, you'll see they're all in the public domain for you to use/copy/reuse any way you like.

Like you, I didn't find anything about it in the source besides "Feel free to customize this file to suit your needs".

Didn't you have problems using OpenGL with Derelict? I tried to use it and it even doesn't compile (tried revision 380 and 384), because with Version (darwin), DerelictGLContext isn't defined and is used as return type for getCurrentContext(). It should probably use something as CGLContextObj.

About your keyboard crash, have you tested with SDL 1.2.13? In the changelog, it states:
Quote:
...
Unix Notes
  • Fixed crash in SDL_SoftStretch() on secure operating systems.
...
Mac OS X Notes
...
  • Fixed high frequency crash involving text input.

Maybe it could help Smile.

Thanks for your very informative post.

Hugues De Keyzer
Back to top
View user's profile Send private message
afb



Joined: 26 Jan 2005
Posts: 137
Location: Sweden

PostPosted: Sun Mar 30, 2008 3:01 am    Post subject: Reply with quote

How to link to SDLmain on Mac OS X has been discussed several times before. Initially the workaround with reimplementing SDLmain was used, but it is not necessary anymore. Here's what the current SDL code is using:

Code:

private extern (C) int _d_run_main(int argc, char **argv, void * p);
int main();

version (darwin) version = SDL_main;
version (GNU) version (Windows) version = SDL_main;

version (SDL_main) {

extern (C) int SDL_main(int argc, char** argv)
{
  return _d_run_main(argc, argv, &main);
}


This uses the regular libSDLmain.a to initialize the objective-c runtime (the errors above), and then calls the Phobos initialization of the garbage collector and then finally calls the regular "main" method of the D program.
Back to top
View user's profile Send private message
aldacron



Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea

PostPosted: Sun Mar 30, 2008 9:08 am    Post subject: Re: Derelict on Mac OS X - another solution Reply with quote

Crispy wrote:

SOLUTION: Here are my proposed framework search paths.

../Frameworks/LIBNAME.framework/LIBNAME
/Library/Frameworks/LIBNAME.framework/LIBNAME
/System/Library/Frameworks/LIBNAME.framework/LIBNAME


I've updated the trunk to search these three paths on Mac for DerelictGL and DerelictSDL*. Someone please let me know if everything works now for these packages with no modification from the trunk.

GLU is not implemented yet. I need to work out a solution to sharing the DerelictGL SharedLib reference on Mac, since OpenGL and GLU are bundled together. The current implementation of the loader doesn't allow for this, so I'll need to give it more than a cursory thought to implement.

Also, I'd love it if someone could verify the paths for the remaining packages. I noticed in Cripsy's older post that none of these paths were used for SDL_image. SDL_image.dylib was used instead. Is that still the case? Which way to go with the other packages?
_________________
The One With D | The One With Aldacron | D Bits
Back to top
View user's profile Send private message Send e-mail
afb



Joined: 26 Jan 2005
Posts: 137
Location: Sweden

PostPosted: Sun Mar 30, 2008 9:22 am    Post subject: Re: Derelict on Mac OS X - another solution Reply with quote

aldacron wrote:

Also, I'd love it if someone could verify the paths for the remaining packages. I noticed in Cripsy's older post that none of these paths were used for SDL_image. SDL_image.dylib was used instead. Is that still the case? Which way to go with the other packages?

All SDL libraries are available as both frameworks (e.g. SDL.framework, SDL_image.framework) and as shared libraries (e.g. libSDL.dylib, libSDL_image.dylib)
Back to top
View user's profile Send private message
Crispy



Joined: 26 Nov 2005
Posts: 67

PostPosted: Mon Mar 31, 2008 7:50 pm    Post subject: Re: SDL and OpenGL with Derelict on Mac OS X Reply with quote

hugues wrote:
I could still run my test program in D by renaming my main() to SDL_main() and linking with libSDLmain.a, but there seems to be a problem concerning memory allocation. Just calling std.string.toStringz() was crashing the program like this:

I guess you need to init the garbage collector. Try calling gc_init(). You may have to declare a prototype for it or the compiler will complain: void gc_init(); The function is in the Phobos lib, so the linker will find it; you just need to shut the compiler up.

Quote:
I was wondering about how to get rid of SDLmain.m and couldn't find an answer before finding your post. I didn't try your solution yet, but I'm confident knowing you succeeded to port your game.

Bear in mind that my solution is not perfect. Of course, if you want to improve on it and release your changes back to the community, I'd be grateful. Wink

Quote:
Regarding SDLmain.m licensing, I found this post where Sam Lantinga writes:
Quote:
In fact, if you look at the SDLmain source files, you'll see they're all in the public domain for you to use/copy/reuse any way you like.

Like you, I didn't find anything about it in the source besides "Feel free to customize this file to suit your needs".

Yes, I saw that post too. I agree it's not clear.

Quote:
Didn't you have problems using OpenGL with Derelict? I tried to use it and it even doesn't compile (tried revision 380 and 384), because with Version (darwin), DerelictGLContext isn't defined and is used as return type for getCurrentContext(). It should probably use something as CGLContextObj.

I had no problems. It's possible I was using an older version of DerelictGL which didn't require that call. I need to make some time to check it out again.

Quote:
About your keyboard crash, have you tested with SDL 1.2.13? In the changelog, it states:
Quote:
...
Unix Notes
  • Fixed crash in SDL_SoftStretch() on secure operating systems.
...
Mac OS X Notes
...
  • Fixed high frequency crash involving text input.

Maybe it could help Smile.

No I haven't; it wasn't out back when I was doing this. I'll definitely have to try that, thanks for pointing it out. Smile


Last edited by Crispy on Mon Mar 31, 2008 7:55 pm; edited 1 time in total
Back to top
View user's profile Send private message
Crispy



Joined: 26 Nov 2005
Posts: 67

PostPosted: Mon Mar 31, 2008 7:53 pm    Post subject: Re: Derelict on Mac OS X - another solution Reply with quote

aldacron wrote:
Also, I'd love it if someone could verify the paths for the remaining packages. I noticed in Cripsy's older post that none of these paths were used for SDL_image. SDL_image.dylib was used instead. Is that still the case? Which way to go with the other packages?

The .dylib stuff was a relic of earlier experiments, as I noted later in that thread. DItch the dylibs; frameworks are the way to go for all current and future libraries, assuming a framework download is available for that particular SDL_* library. The libraries I used all had one.
Back to top
View user's profile Send private message
hugues



Joined: 09 Aug 2007
Posts: 20
Location: Brussels, Belgium

PostPosted: Tue Apr 01, 2008 1:18 pm    Post subject: Re: SDLmain on Mac OS X Reply with quote

afb wrote:
How to link to SDLmain on Mac OS X has been discussed several times before. Initially the workaround with reimplementing SDLmain was used, but it is not necessary anymore.

...

This uses the regular libSDLmain.a to initialize the objective-c runtime (the errors above), and then calls the Phobos initialization of the garbage collector and then finally calls the regular "main" method of the D program.


Indeed, I found your page thanks to the other post that aldacron refers to. That is great for programs that want to use SDL and OpenGL by linking normally to the libraries (for users who don't understand how great is Derelict Wink). Your page was a little hard to find. Is there a central place where all D headers to popular libraries can be found? It would be great if there was a clear link to such a place on the Digital Mars "D Links" page.
Back to top
View user's profile Send private message
hugues



Joined: 09 Aug 2007
Posts: 20
Location: Brussels, Belgium

PostPosted: Tue Apr 01, 2008 1:38 pm    Post subject: Re: Derelict on Mac OS X - another solution Reply with quote

aldacron wrote:
Crispy wrote:

SOLUTION: Here are my proposed framework search paths.

../Frameworks/LIBNAME.framework/LIBNAME
/Library/Frameworks/LIBNAME.framework/LIBNAME
/System/Library/Frameworks/LIBNAME.framework/LIBNAME


I've updated the trunk to search these three paths on Mac for DerelictGL and DerelictSDL*.

I noticed that the first path in each header is now ./Frameworks/LIBNAME.framework/LIBNAME. Shouldn't it be ../Frameworks/LIBNAME.framework/LIBNAME (with two dots), like Crispy suggests?

aldacron wrote:
Someone please let me know if everything works now for these packages with no modification from the trunk.

Well, as I said above, simply importing derelict.opengl.gl prevents the program from compiling with the following error:
Code:
derelict/opengl/gl.d:210: Error: identifier 'DerelictGLContext' is not defined
derelict/opengl/gl.d:210: Error: DerelictGLContext is used as a type
Indeed, DerelictGLContext is not defined for version (darwin). I think we are supposed to use something like CGLContextObj for that. Do we need the functions that use DerelictGLContext on the Mac? If you want, I can make a header for CGL (Core OpenGL, the equivalent of GLX and WGL on Mac OS X).

Thanks for the good work, I think Derelict is great.
Back to top
View user's profile Send private message
hugues



Joined: 09 Aug 2007
Posts: 20
Location: Brussels, Belgium

PostPosted: Tue Apr 01, 2008 2:33 pm    Post subject: Re: SDL and OpenGL with Derelict on Mac OS X Reply with quote

Crispy wrote:
hugues wrote:
I was wondering about how to get rid of SDLmain.m and couldn't find an answer before finding your post. I didn't try your solution yet, but I'm confident knowing you succeeded to port your game.

Bear in mind that my solution is not perfect. Of course, if you want to improve on it and release your changes back to the community, I'd be grateful. Wink

Maybe it's not perfect, but it seems to work very well. I adapted my little test program just after writing my first post about this the other day, and I got a nice window after just a few minutes work. It took me some instants to notice that it worked, though: the window was appearing behind my terminal window (which was completely hiding it). I noticed it thanks to the transparency of the window (thanks iTerm Wink). If the program is launched from a terminal, the SDL window (probably because it is not a full-fledged application) doesn't come to the foreground, cannot get the focus (and thus the keyboard input), and its name is not shown in the menu bar next to the Apple logo like other apps. All these little problems don't appear if the program is launched from an application bundle, or when the SDL window is full-screen (even when launched from a terminal, then).

Also, I succeeded in releasing the AutoreleasePool without any errors. I think it was a problem regarding the SDL version (I'm using 1.2.13), because I didn't had to change anything for it to work. I just called destroyAutoreleasePool(). Even better, the whole NSApplicationLoad() / createAutoreleasePool() / SDL_Init() / SDL_Quit() / destroyAutoreleasePool() process can be done as many times as you want. I had to remove the donePlatformInit test for it to work, because the AutoreleasePool has to be created if we want to release it each time.

SDL itself creates and releases an NSAutoreleasePool in QZ_PumpEvents() (probably called several times each frame), so I think there's no need to worry about releasing the pool each frame or something like that.

Some things left to improve:
  • When launched from an application bundle, the application menu appears correctly, but the Quit command doesn't work ("could not find associated NSMenu for -20213 (item:9)"). (However, closing the window generates a SDL_QUIT event.)
  • The "window not a full-fledged app" problem when launched from a terminal, as explained above.
I will look into this when I will succeed in getting all this to work with Derelict.

Crispy wrote:
hugues wrote:
About your keyboard crash, have you tested with SDL 1.2.13?

No I haven't; it wasn't out back when I was doing this. I'll definitely have to try that, thanks for pointing it out. Smile

You're welcome Wink.
Back to top
View user's profile Send private message
aldacron



Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea

PostPosted: Tue Apr 01, 2008 8:00 pm    Post subject: Re: Derelict on Mac OS X - another solution Reply with quote

hugues wrote:

I noticed that the first path in each header is now ./Frameworks/LIBNAME.framework/LIBNAME. Shouldn't it be ../Frameworks/LIBNAME.framework/LIBNAME (with two dots), like Crispy suggests?


That's a copy-pasted typo. Thanks for catching it.

Quote:
Indeed, DerelictGLContext is not defined for version (darwin). I think we are supposed to use something like CGLContextObj for that. Do we need the functions that use DerelictGLContext on the Mac? If you want, I can make a header for CGL (Core OpenGL, the equivalent of GLX and WGL on Mac OS X).


It's not implemented yet because I don't have a Mac Smile I should be getting one later this year, but I've been hoping for a long while that someone would contribute Mac gl module. If you're up to it, I'll be happy to drop it in the trunk.
_________________
The One With D | The One With Aldacron | D Bits
Back to top
View user's profile Send private message Send e-mail
revcompgeek



Joined: 24 Nov 2007
Posts: 27

PostPosted: Fri Apr 04, 2008 11:37 pm    Post subject: Reply with quote

So with the most recent changes, the only thing that needs to be done is adding the NSAutoreleasePool call?
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> Derelict All times are GMT - 6 Hours
Goto page 1, 2, 3, 4, 5, 6  Next
Page 1 of 6

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group