The carbon version of my game uses ReceiveNextEvent, which is called a every frame, for a fraction of time, to receive events (obviously). This is in sync with the PC version of the game. I want to make this in sync yet again with the Cocoa version of the game--how would I go about this? I do not want to use a NSTimer for the main event (which would implement the sleep needed), as I would have to make a custom event loop for Cocoa, and another version for the Carbon/Windows version.

So in short, is there an equivalent of ReceiveNextEvent in Cocoa?

Thanks

pass [NSDate distantPast] for untilDate to make it return immediately.

You might like to look up the original Omni group presentation on porting games to Mac OS X, it contains a good example of this.

Be aware you bypass the entire event handling mechanism by doing this, you will need to dispatch some of these events to the appropriate places yourself.

Could I not just take the event from nextEventMatchingMask, and then send it back to my NSApplication, which could then be processed with mouseDown, keyDown, etc?

This way, it would be:
1. NSApp loop->
2. Game Loop-> [checkforevent] -> render ->update game specifics
3. Repeat 2 Until quit.

and in the [checkforevent], it would shoot my events out of the gameloop, and to my specified mouseDown/etc codes in my controller?

maaaaark Wrote:Could I not just take the event from nextEventMatchingMask, and then send it back to my NSApplication, which could then be processed with mouseDown, keyDown, etc?

This way, it would be:
1. NSApp loop->
2. Game Loop-> [checkforevent] -> render ->update game specifics
3. Repeat 2 Until quit.

and in the [checkforevent], it would shoot my events out of the gameloop, and to my specified mouseDown/etc codes in my controller?

Sure you could.

It's weird, I check for input way into my game engine's C++ code... and perform the [NSApp nextEventMatchingMask ...], and then i relay it to my controller by:

[[NSApp delegate] myspecialeventhandlingfunction:event eventType:[event type]];

However results are widely varying, and some things are not inconsistent (such as the About game... menu item not working now and then--sometimes even crashing the game).

very very odd...

this might be the final blow for me to move to Carbon (which I don't want to do... there seems to be many things I can do easier on the data/setup side in Cocoa...)

Then why not let Cocoa handle the events for you?

I have to plug in my code to the crossplatform engine. Their loop is:
1. update game stuff
2. check for user input (this is where i'd break to NSApp to get the last event
3. render

this is all housed in an infinite loop until a boolean is true (for quit).

I could use timers, but that'd ruin the whole crossplatform / same code ideal.

Ahem, an "ideal" which is not ideal at all. The event loop is clearly something that is VERY platform specific, and it's easier to create a proper event loop than try a hack like you are suggesting. I've been there. We used a loop for windows, for lack of better, and a proper event driven architecture for OS X.

I'm weighing my options. There is no need to move to Cocoa at all--our Carbon code works fine. There is just many things I find that I can do easier in Cocoa. I think I am just going to create a Mac OS X specific event structure as you suggest.

Even in Carbon you should use a proper event loop. If you want a cross platform example, I can dig it up in my code.

I would love to see cross platform examples... is it carbon only?

Would multiple threads affect the main thread's (AppKit's) event functionality? For some reason my game crashes (with NSTimer being used) when I try to access my About Game menu item. My game uses several threads for loading files / OpenGL rendering / Audio

Not all of Cocoa is thread-safe.

I am transplanting my game from carbon to cocoa. the threads are pretty non-platform specific. none of the threads really utilize any cocoa specific classes or methods, save OpenGL drawing. but even that is mostly OpenGL specific code, utilizing correct lock/unlocks. Sound is handled by FMOD, which I believe is Carbon. File management is non-cocoa as well. The only thread utilizing Cocoa would be the initial thread thread which spawned the App. And all that does is pickup events / handle UI / start game with NSTimer.

Now that I'm saying it's multithreaded, it may not have been the AppKit thread that crashed, but it might have just been at the top of the crash report. oop ;P I'll have to investigate further.

The crash report has multiple threads listed, from Thread 0 to Thread x. There should be an indicator CRASHED next to whichever thread was the one that crashed in the crash report. Look for that one.