Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (780)
Games in Android Showcase (233)
games submitted by our members
Games in WIP (857)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Executing logic outside "game loop" thread  (Read 3758 times)
0 Members and 1 Guest are viewing this topic.
Offline 8ballj

Senior Newbie

« Posted 2009-02-18 01:27:28 »

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.

Offline donmc

Junior Devvie

Projects: 1

« Reply #1 - Posted 2009-02-18 10:21:36 »

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

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!
Offline Orangy Tang

JGO Kernel

Medals: 57
Projects: 11

Monkey for a head

« Reply #2 - Posted 2009-02-18 11:02:34 »

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.

[ - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline 8ballj

Senior Newbie

« Reply #3 - Posted 2009-02-18 19:55:21 »

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!
Offline cylab

JGO Kernel

Medals: 188

« Reply #4 - Posted 2009-02-18 22:36:05 »

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.

Mathias - I Know What [you] Did Last Summer!
Pages: [1]
  ignore  |  Print  

hadezbladez (761 views)
2018-11-16 13:46:03

hadezbladez (394 views)
2018-11-16 13:41:33

hadezbladez (758 views)
2018-11-16 13:35:35

hadezbladez (200 views)
2018-11-16 13:32:03

EgonOlsen (2401 views)
2018-06-10 19:43:48

EgonOlsen (2581 views)
2018-06-10 19:43:44

EgonOlsen (1486 views)
2018-06-10 19:43:20

DesertCoockie (2149 views)
2018-05-13 18:23:11

nelsongames (1967 views)
2018-04-24 18:15:36

nelsongames (2648 views)
2018-04-24 18:14:32
Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08

Deployment and Packaging
by gouessej
2018-08-22 08:03:45

Deployment and Packaging
by philfrei
2018-08-20 02:33:38

Deployment and Packaging
by philfrei
2018-08-20 02:29:55

Deployment and Packaging
by philfrei
2018-08-19 23:56:20

Deployment and Packaging
by philfrei
2018-08-19 23:54:46 is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!