I went ahead and used timers, just to get things off the ground. Many people seem to dislike them, but they work for me, for now anyway. It's really helpful to know about CVDisplayLink, though, if I ever implement graphics or need a more strict timing solution. Thanks for the response. On Dec 16, 2013, at 6:15 PM, Dan Treiman <dtrei...@mac.com> wrote:
> Alex, > > Ah, this has been a continuous discussion ever since OSX launched… :-). > Heres my 2¢: > > The two best solutions (and by best I mean least time-wasting) are > CVDisplayLink and NSTimer. > > CVDisplayLink synchronizes with the display refresh rate and gives you > callbacks in a background thread. This somewhat like CADisplayLink on iOS. > Its pretty easy to do but your code must be thread-aware. > > NSTimer has more than enough resolution for games, and if you are using > OpenGL for graphics you should do: > GLint swapInt = 1; > [[self openGLContext] setValues:&swapInt > forParameter:NSOpenGLCPSwapInterval]; > to ensure your updates are synced with screen refresh. > > Since your game does not sound especially graphically intensive, I would > recommend the solution that requires the least code written (NSTimer), and > avoid multithreading. If you run into performance problems you can always > implement a more advanced solution later. > > cheers, > - Dan > > > On Dec 13, 2013, at 3:57 PM, Alex Hall <mehg...@gmail.com> wrote: > >> Hello list, >> I am attempting to use OpenAL to move a sound source around. To do so >> smoothly, though, will require a loop, so I can update the position in small >> increments many times per second. This is essentially a game loop, so I've >> done much searching on implementing game loops in Objective-C. There seem to >> be a few schools of thought on the topic: >> >> NSTimer: it works initially, but you can't rely on it to provide smoothness >> or constant rates. A timer could take up to 0.1 seconds to execute, so don't >> rely on it. However, other sources suggest that a timer will work just fine, >> particularly on the more powerful OSX compared to iOS devices, and doing >> anything else is a waste of effort for lower FPS projects. >> >> Main loop: every NSApplication has an instance of NSRunLoop attached to it >> when it starts. Hook into that (the mechanics of doing this are still not >> clear to me) and you are good to go. However, this is more work for no >> additional benefit, and you need to worry more about memory usage (I have no >> idea if the samples I've read were using ARC or not). >> >> Separate thread: uses standard-issue while(keep_running) loop in a new >> thread to process the game logic and refresh the world, and you're set to go >> as fast as you need to. However, this introduces the usual multi-threading >> concerns and is far more advanced than many projects actually need. >> >> Additionally, there is concern about how fast to set the refresh rate, which >> is not a problem in a regular while loop but becomes a bit complex >> otherwise. Most people seem to agree that you should see how long the last >> cycle took, and update your interval accordingly. >> >> Again, this is not (yet) for iOS, so I cannot rely on iOS-specific >> solutions. I am also not currently doing visuals, and I am not sure which >> framework I will use when and if I need to begin doing so, so I'd rather >> have my loop not rely on any visual framework. The bottom line seems to be >> that timers are easiest but not reliable, yet some people insist they will >> work well enough. So, what are your thoughts on the best way to make a game >> loop for OSX? While I would like to port this project to iOS in the future, >> I'd like a solution that will work on both platforms, and the Mac first. >> Given that my program is mostly based in sound, would timers be okay? Should >> I look into hooking into the NSRunLoop somehow instead? I'd really rather >> not go multi-threaded yet, but if I have to, I have to. Thanks for your >> opinions. >> >> >> Have a great day, >> Alex (msg sent from Mac Mini) >> mehg...@gmail.com >> >> >> >> >> _______________________________________________ >> >> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) >> >> Please do not post admin requests or moderator comments to the list. >> Contact the moderators at cocoa-dev-admins(at)lists.apple.com >> >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/cocoa-dev/dtreiman%40mac.com >> >> This email sent to dtrei...@mac.com > Have a great day, Alex (msg sent from Mac Mini) mehg...@gmail.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
