Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

Coolest resynchronisation method ever

Sign in to follow this  


If my renderer and physics threads desynchronise too much (usually resulting in the renderer trying to draw snapshots that haven't been generated yet), the renderer just assumes that the system clock is wrong and subtracts an offset to get back to where the updates are valid. [grin]

Because the timer that kicks my physics update is event-based, holding up the event loop will cause physics updates to stop and the renderer to continue (e.g. by pulling down a menu from the menubar). So that's why that's necessary.

I also wrote a nice assertion routine. Folks, assert() may be good when you've got nothing better, but really, it's worth taking the time to throw something together with an NSAlert that has "Break" and "Ignore" buttons. Most of the assertions I put into code are recoverable from - they're just indicative of weird behaviour, or of things that I do need to fix but not immediately. Standard library assert() calls through to kill() with a SIGTERM (IIRC) which means that the moment an assertion fails you're SOL. Writing your own ASSERT() macro also eliminates any need for crazy 'expr && message' tricks, as seen in GPG.

Next, I'm going to get input working via the HID stuff. Should be fun; I think it'll work in a way somewhat similar to DirectInput, or at least, I can get both MacHID and DirectInput working under a common interface that isn't too horrible.

I'm starting to enjoy it more and more. XCode's debugger integration is pretty poor - XCode has a tendency to think that the app is still running when it has stopped, etc - but once you get over the initial 'Where's my message loop? Where's my startup/shutdown functions?' platform shock, it's quite pleasant.

The funniest thing is the reactions I get from some of the people in the #idevgames chat channel, because it seems there's a certain established way of doing things on Mac and it's a bit different from the crazy-assed multithreaded pedal-to-the-metal techniques I'm bringing with me from the PC. Oh, the dirty looks I got when I tried telling someone that making everything a Cocoa object with accessors wasn't necessarily the way to go...

FYI: If you're interested in getting into Mac development, I would recommend Cocoa. Objective-C looks pretty nasty - it's lacking some of the things that one comes to expect in object-oriented languages, like constructors - but Cocoa has a tendency to fill in the gaps (e.g. by providing 'init' and 'dealloc' methods on NSObject, the object from which all others are inherited). Give the application a delegate object to handle -(void)applicationDidFinishLaunching() amongst other things, kick off your threads from there, and you're away.

I think I really should write an article on this when I'm done - there's one Mac article in GDNet's library, and it's not even one of our own.
Sign in to follow this  

1 Comment

Recommended Comments

Yeah, I tried my hand at Carbon yesterday, and I have to say I wouldn't go back to it.

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!