Executing logic outside "game loop" thread

[8ballj]

I've set up a turn based strat game that relies solely on mouse clicks from the user.  I have a main loop that merely draws the world, then sleeps for the excess time.  This same runnable object that contains the loop also is the mouse listener.  When the mouse listener gets an event, it relays the event down to the main "game logic" class to perform some calculation... however this is done on the fly and totally independent from the main loop.  Is this a dangerous way to design the game despite only having very isolated moments of working game logic?

Another slightly related question is using Thread.sleep(excess time) vs. Thread.yield() and if one would hurt the Event Dispatching Thread "liquidity" more than the other.  I've been using Thread.yield() and it kills any machine I run the game on.  Thread.sleep() however barely uses any processor so I'm inclined to use it instead especially if there is no disadvantage.

Thanks,
jon

[donmc]

bleh, I typed up a reply only to have IE gobble it up when it became self aware.   

Attempt #2:

I don't see a problem with dispatching the mouse events directly to your game logic class from your main loop thread.  I also don't see a problem with using sleep() instead of yield().  You *could* pipe the caught mouse events through your game loop thread and then to your logic class, but that's just an extraneous step.  If you only want to act on the mouse information as certain times you can always just sit on the information until you are ready to process it in your logic class. 

Those mouse events are coming to your from another thread however.  If your game loop/logic thread(s) are modifying the same data as your mouse listener methods are modifying you will get a concurrent access modification exception.  You will need to synchronize the methods and/or use synchronized code blocks to avoid the problem.

For example say you have a group of mobs onscreen that you store in a list using the java collections.  If you get a list iterator and are running over the list, and at the same time you catpure a mouse event that needs to delete one of those mobs (maybe you shot it), calling mobs.remove() is going to cause your program to go crash-boom because the first thread was iterating over the list while the second thread tried to modify it.  Again though using synchronized methods, synchronized code blocks, or in this case a sychronized list will fix the problem.

good luck!
~don

[Orangy Tang]

Unless you've got a really good reason to then try and keep everything happening in your main thread. When your mouse events come in just log them in an input queue and flush that at the appropriate place in your game loop. That means you only have to make a tiny part of your game thread-safe. Scattering synchronized everywhere and trying to make your entire game thread-safe is difficult, error prone and adds a lot of unnecessary overhead.

Games published by our own members! Check 'em out!

[8ballj]

Thanks for the replies guys.  I'm not sure I would get any concurrent access modification errors because I never explicitly iterate over a collection.  The drawing is done through for-loops on a master array.  All logic accesses the object to-be-modified directly, no iterators.  I went ahead and piped the mouse input into the game loop anyways though, where logic is now being processed at the FPS. 

The mouse clicks feel slightly more responsive now that I am intentionally checking for them at my FPS rate, so that is a good thing!

[cylab]

thread safety is not about concurrent modification exceptions but about objects having inconsistent states because of still running updates while already using them or because some memory<>(multi-)cpu cache synchronization issues.