Jens Afke wrote: > You've basically implemented coroutines, actually a simple form of > an actor, using multiple threads. Each coroutine is running an event > loop, and the game one blocks waiting for incoming events from the UI > one.
/.../ > This is a fine way to do things, except that you can't call AppKit > from the game thread, and in general have to be careful about > accessing shared state. More subtly, you've written your game code > with the expectation that, each time it waits for user input, there is > only one type of input the user can enter. For example, you wait for > the user to enter a new note to play. Agreed. > If the game gets more complex, there may be multiple types of things > the user can do (maybe deleting or editing notes) and then your code > has to add something like a switch() statement to handle each possible > action. In my experience, this quickly becomes unwieldy and results in > spaghetti code, at which point the regular asynchronous event-loop > mechanism becomes cleaner. (Historically this is a prime reason why > GUI libraries use it in the first place.) Definitely agreed. But that is not the type of thing my game is intended to do. Thanks for helping me a little with terminology, though! Since I'm just a hobbyist I get stuck not being able to explain what I want to do, cause I don't know what it's called... :) _______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
