Re: Blocking for input during a loop?
Re: Blocking for input during a loop?
- Subject: Re: Blocking for input during a loop?
- From: Per Bull Holmen <email@hidden>
- Date: Tue, 19 Jan 2010 10:26:28 -0800 (PST)
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 (email@hidden)
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:
This email sent to email@hidden