Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (499)
Games in Android Showcase (118)
games submitted by our members
Games in WIP (568)
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  
  2 Thread one for drawing and one for logic  (Read 2145 times)
0 Members and 1 Guest are viewing this topic.
Offline stef569

Junior Member





« Posted 2007-11-24 21:06:29 »

Hi, After some thinking I tought that the logic would be better off in a different Thread then the drawing code.

So I create 2 Threads and fire them both off.
I know to cap the fps in the view Thread, but what about logic? :s
In killergaming the author describes how to call multiple logic updates when the frame is bigger then the desired frame length. To come closer to the desired fps...
But how do you count updates per second then, and how do you tell how many updates should be done in one frame, 1 2 or mayby 3?

also In the javadoc of thread is stated that when the wait command is done, locks remain on objects.
So if this situation occurs( A new score)
In the logic Thread:
controller.setScore(5)
In the view Thread:
logic.wait
controller.getScore
a deadlock would happen right? Angry
Offline Coinerson

Junior Member




Introducing the world's cutest zombie, Timmy


« Reply #1 - Posted 2007-11-24 21:08:21 »

Your making it much more difficult than it needs to be.
Offline malberts

Junior Member





« Reply #2 - Posted 2007-11-24 21:22:36 »

I don't think you need to create an extra Thread for the logic. Remember that a program is already a thread itself. So when you create a seperate Thread for your graphics it is seperate from the normal program. You can do the logic in there.

Regarding the update skips: your game loop gets the time before it runs and after it runs. You then determine the sleep time. Suppose you want 50 FPS, that would mean 1 update, 1 render, 1 draw every 20ms. Now say the loop takes 44ms to complete. That means you've used the time for 2 loops. So you store the time that was overspent and during the next loop you make up for that by doing extra updates for every 20ms subtractable from the time overspent. You can also specify a max number of updates to be repeated as well.

All of this is covered in Killer Game Programming in Java.

In space no-one can hear you System.out.println()
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline stef569

Junior Member





« Reply #3 - Posted 2007-11-25 01:20:51 »

Thanks for the reply,
Quote
I don't think you need to create an extra Thread for the logic. Remember that a program is already a thread itself. So when you create a seperate Thread for your graphics it is seperate from the normal program. You can do the logic in there.

Please correct me if i'm wrong
There is my own Thread drawing & doing logic Logic because it calls logic() as a function inside the Thread run method.
The program Thread that creates the objects, or does it do more?
The key, mouse events Thread

Also I now better understand that it is all about the fps, more ups is not needed, only when frames are running behind.
Offline broumbroum

Junior Member





« Reply #4 - Posted 2007-11-25 04:24:55 »

you can have as much thread as you want to. But regardless to the heap size of your resulting thread-stack, it is important to group the whole as a threading-tree (see ThreadGroup), know I'm saying? then, using more threads can become interesting at the engine-acceleration level. Wink

pay attention to the fact that the more threads you create simultaneously, the longer you'll spend your time to get the whole stuff synchronized. So I'd suggest you to focus on what resources are used from "drawing" and "logic". but that's alright.   Grin Grin Grin Grin Grin Grin

::::... :..... :::::: ;;;:::™ b23:production 2006 GNU/GPL @ http://b23prodtm.webhop.info
on sf.net: /projects/sf3jswing
Java (1.6u10 plz) Web Start pool
dev' VODcast[/ur
Offline malberts

Junior Member





« Reply #5 - Posted 2007-11-25 11:19:55 »

My apologies, I was thinking about something else here. Yes, the logic is called from the Thread which handles updating/rendering/drawing.

Have a look at this:
Here's a simple game loop:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
   START
     |
 INITIALIZE
     |
  [loop]<-----.
     |        |
   logic      |
     |        |
draw objects  |
     |        |
[finished?]---^ no
     |
     | yes
  CLEANUP
     |
   EXIT


To control the FPS you need to know how much time elapsed from the beginning of the game loop to the end of the game loop. If everything is in one Thread then it's easy, just take the time before and after and determine the sleep time and if it's necessary to do extra updates.

If you are going to use a separate Thread for logic then you're going to run into this:
If the logic Thread takes longer to execute than the Draw Thread then you're never going to be drawing the state correctly:
This tables shows the total time elapsed and the loop nr for the logic and draw.
timelogicdraw
1011
2012
3023
4034
5035
I'd say the time taken during the drawing routine would be roughly the same every loop, but the time needed for the logic can change more due to whatever is currently happening. So in the above table your drawing loop is going to be drawing along happily while the logic Thread is still trying to figure out what moves where. If the inverse was going to happen (ie. updates quicker than drawing) then you're going to have updates not drawn to the screen. So in the worst case you're either going to have updates skipped, or resources wasted due to excessive drawing. To ensure this doesn't happen you're going to have to synchronize the threads and that will probably be by having the one thread wait for the other to finish one iteration of the loop.

If you take a look at the single Thread method then that is exactly what is happening. So basically in the single Thread the drawing follows the logic so you don't have to synchronize. Now if the loop was to take longer than the required time then you just add a few extra updates in the next loop iteration until you're on time again. So in both cases you might have updates skipped, but there's less to take care of in the single Thread method.

I have done a simple shooter base on the KGPJ book using his single Thread method and it works fine. You just have to take care to not place the game logic directly into the GPanel class.

In space no-one can hear you System.out.println()
Offline broumbroum

Junior Member





« Reply #6 - Posted 2007-11-25 12:04:26 »

seems to get best effort from each threads, but that can be annoying if you want to skip frames. Hence a more precise desc. may be necessary, as I have one logical structure already running fine :
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
Sprite <- [got the image loaded in IO cache]
Animation <- [got the sprites buffer loaded in cache]
Model <- [got the animations buffer loaded in cache]
 ^---------------- waits for offscreen to be painted for 3 sec. limitation, the main rendering Timer (> 3 sec. frame is skipped)
 ^----------------- offscreen/buffer Timer waits for the main rendering Timer to finish 1-frame-rendering task

Model has one more subclass : InteractiveModel that processKeyEventsStack() right before painting.
All Component validation methods are held on a separate Thread stack (ThreadGroup) and all paint() methods are waiting for the Component to be declared valid. Sprite, Animation and Model extends JComponent but are used for active rendering throughout a dedicated draw(Graphics, AffineTransform).

Summary :
Total threads : JComponent have 1 validation Thread each (+ 1 for Animation buffering)+ main render scene 2x1 Timer each for buffer and paint + InteractiveModel has 1+ extra Thread stack for KeyEvents reading/validation = 4+ Threads count all running at priority level 5-10 (NORM < lvl < MAX)
logic will be held in 1 extra Threads nearby the KeyEvents, naturally.

 Cheesy

::::... :..... :::::: ;;;:::™ b23:production 2006 GNU/GPL @ http://b23prodtm.webhop.info
on sf.net: /projects/sf3jswing
Java (1.6u10 plz) Web Start pool
dev' VODcast[/ur
Offline appel

JGO Wizard


Medals: 51
Projects: 4


I always win!


« Reply #7 - Posted 2007-11-25 12:34:21 »

You gain nothing by drawing the screen 10 times if the logic has only been updated once! It's the same screen that has been drawn 10 times!

Multithreading is more troublesome than it's worth if you're doing simple games. Make sure you use it properly.

This is actually a big interest to me, how to utilize these multicore processors, I don't think there are any games libraries in Java that split concerns up in threads.

Check out the 4K competition @ www.java4k.com
Check out GAMADU (my own site) @ http://gamadu.com/
Offline malberts

Junior Member





« Reply #8 - Posted 2007-11-25 15:13:38 »

I'm no expert on threads, but the way I see it is that you only split into threads if those parts should run concurrently.

The Thread used in the game panel is used to split Swing/AWT from the game loop. That way your input handling works independently from the rest. If it wasn't done this way you would have to pause everytime you wanted input. I understand the reason for why you want to do the split to keep unrelated items apart. But you should not see it as the logic being part of the drawing. The logic and drawing are both part of the game loop (which runs in its own Thread).

If your logic is very resource intensive then you could split your logic into threads to, say, run them on multiple cores. But then the drawing section should still follow the logic and not run concurrently with it.

Just keep in mind that the game loop is a linear process, the subsections can be subdivided into threads but the overall game loop should be kept as a single process.

In space no-one can hear you System.out.println()
Offline cylab

JGO Ninja


Medals: 50



« Reply #9 - Posted 2007-11-25 18:18:21 »

You gain nothing by drawing the screen 10 times if the logic has only been updated once! It's the same screen that has been drawn 10 times!

Depends how you set up your logic. You can for instance use simple direction/velocity calculations every frame and more advanced stuff that updates the parameters for the former in a long living thread. This way you can let your objects move on screen, while you are calculating the next logical update.

If your logic is very resource intensive then you could split your logic into threads to, say, run them on multiple cores. But then the drawing section should still follow the logic and not run concurrently with it.

This could be achieved by waiting for your logic thread(s) to finish in the game loop before drawing the next frame. To effectively make use of multicores, you may need a thread pool, to which you can pass "jobs" to be done on the next free "execution slot".

Mathias - I Know What [you] Did Last Summer!
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline stef569

Junior Member





« Reply #10 - Posted 2007-11-27 13:13:57 »

Thx for the replies
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Riven (10 views)
2014-10-02 14:36:20

Pippogeek (41 views)
2014-09-24 16:13:29

Pippogeek (32 views)
2014-09-24 16:12:22

Pippogeek (22 views)
2014-09-24 16:12:06

Grunnt (48 views)
2014-09-23 14:38:19

radar3301 (30 views)
2014-09-21 23:33:17

BurntPizza (65 views)
2014-09-21 02:42:18

BurntPizza (37 views)
2014-09-21 01:30:30

moogie (44 views)
2014-09-21 00:26:15

UprightPath (53 views)
2014-09-20 20:14:06
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org 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‑gaming.org
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!