Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (121)
games submitted by our members
Games in WIP (577)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  questions about the threads. help  (Read 3158 times)
0 Members and 1 Guest are viewing this topic.
Offline 002-Sy

Senior Newbie





« Posted 2013-01-14 07:19:42 »

Well, my question is, how many threads are used in a complete game?
a single thread to the player ?
a single thread for each enemy ?
thread for coliciones ?
a thread just to repaint the screen?
must be synchronized?
Can overheat the processor?
 Huh

Please, help

Offline jonjava
« Reply #1 - Posted 2013-01-14 07:23:02 »

A single Thread is used most commonly. This thread runs the game loop.

The game loop handles game updates (player movement, enemy movements, bullets, calculations.. etc) and rendering (draws stuff on screen).

Offline jonjava
« Reply #2 - Posted 2013-01-14 07:24:09 »

Take a look at clickermonkeys tutorial:

http://www.gameprogblog.com/generic-game-loop/

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline 002-Sy

Senior Newbie





« Reply #3 - Posted 2013-01-14 07:41:34 »

thanks for the reply.
I'll read the tutorial.

but, and sorry for the dumb question.
it's about the speed of game.
 loading many images (bullets like Mushihime-Sama) and the method by which the collision is detected (using the method getBounds with fors)
the game would become very slow?
Offline jonjava
« Reply #4 - Posted 2013-01-14 07:53:38 »

Making games isn't always easy. Most importantly you must know that Threads don't speed anything up.

So having more Threads doesn't make the game loop or collision detection magically faster.

Offline jonjava
« Reply #5 - Posted 2013-01-14 07:56:47 »

loading many images (bullets like Mushihime-Sama) and the method by which the collision is detected (using the method getBounds with fors)
the game would become very slow?

Just to emphasize, this does not make the game become very slow. This is generally the right and correct way of doing simple collision detection.

There are always room for optimizations but NEVER EVER optimize ahead of time. Looking at screenshots of this mushima game, I think it'll be just fine.

Offline 002-Sy

Senior Newbie





« Reply #6 - Posted 2013-01-14 08:14:41 »

thanks for the replies.
So all that remains is to find a way that works well, the times for the animation, movements, etc.
Ok, I'm going to give it my best and try everything you said.
Thanks again.  Wink
Offline Varkas
« Reply #7 - Posted 2013-01-14 11:11:38 »

Making games isn't always easy. Most importantly you must know that Threads don't speed anything up.

So having more Threads doesn't make the game loop or collision detection magically faster.

If you have:

- A cpu with multiples cores or multiple CPUs
- Tasks which do not depend on each other and can run concurrently

you can get a speedup by using multiple threads. Be warned though, using more than one thread opens up a whole new class of bug types, which are particularly hard to debug and fix.



if (error) throw new Brick(); // Blog (german): http://gedankenweber.wordpress.com
Offline Roquen
« Reply #8 - Posted 2013-01-14 12:07:06 »

Most importantly you must know that Threads don't speed anything up.
Err...no.  A beginner probably doesn't want to muck with explicit multi-threading, but done correctly multiple threads DO speed things up the majority of the time.  Up to 25% more processing per core isn't uncommon.
Offline Cero
« Reply #9 - Posted 2013-01-14 13:12:13 »

Mushihime-sama may be a bullet hell game, but remember its only a lot of bullets to the player - not to the CPU
even if there are 200 bullets on the screen and you check all of them for collision with the player, thats only 200 iterations per frame right there; and thats raw simple code without ANY optimization, and its mostly fine

Most importantly you must know that Threads don't speed anything up.
Err...no.  A beginner probably doesn't want to muck with explicit multi-threading, but done correctly multiple threads DO speed things up the majority of the time.  Up to 25% more processing per core isn't uncommon.
IF done RIGHT.
Looking at many PS3 ports which are incredible inferior, due to the complex 8 core architecture of the PS3. Even triple A studios cannot get it right.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Roquen
« Reply #10 - Posted 2013-01-14 13:18:59 »

Luckily we don't need to worry about master/slave semi-transputer architectures.  Also the future is multi-core...if you consider the future to be currently commonplace stuff.
Offline Cero
« Reply #11 - Posted 2013-01-14 13:31:57 »

Luckily we don't need to worry about master/slave semi-transputer architectures.  Also the future is multi-core...if you consider the future to be currently commonplace stuff.

well I'm pretty sure that there will be frameworks which automatically take your code and classes and distribute it to the cores
as it already happens of course, just actually efficient using extra libraries and that sort of thing...

Offline jonjava
« Reply #12 - Posted 2013-01-14 14:26:54 »

Threads by themselves don't speed anything up.

Even with multiple cores multiple threads within an application rarely speed things up. Speed != multitasking.

Since we've sort of hit the cap on CPU speed our processors have in recent years started to become equipped with more and more cores.

Utilizing all cores within a single application is not a trivial task and it's quite a new problem/opportunity.

Offline Roquen
« Reply #13 - Posted 2013-01-14 14:54:05 »

Quote
Threads by themselves don't speed anything up.
Having an appropriate number of threads (active in a given time-slice) allow CPUs to do productive work when they would otherwise be stalled (doing zero work).  So yes...properly done they do.  By how much depends on many many factors.

Quote
Even with multiple cores multiple threads within an application rarely speed things up.
Only if you're doing it wrong.  It's rarely expected that computational power is multiples by the number of physical CPUs however.

Quote
Utilizing all cores within a single application is not a trivial task and it's quite a new problem/opportunity.
Multi-threading certainly requires experience, but it's worthwhile.  The biggest problem is that people, even with experience, always seem to want to over-engineer the problem.

My point isn't: Hey run out and write your game mult-threaded...it's let's be sane about what we're saying.
Offline 002-Sy

Senior Newbie





« Reply #14 - Posted 2013-01-14 17:43:42 »

In general the question of the threads emerged the idea of ​​a double dragon style game.
I had to make a thread for each enemy behavior, considering the shotters (I thought they were more difficult to program).
The processor  began to warm and in linux the game was very slow.
Do you have something to do with the poor implementation of the threads?  Clueless
Offline Roquen
« Reply #15 - Posted 2013-01-14 17:56:01 »

Yeah, you don't use real threads for small tasks. (OK...actually sometimes you do, but that's a different story).
Offline sproingie

JGO Kernel


Medals: 202



« Reply #16 - Posted 2013-01-14 21:40:14 »

If you find yourself typing "new Thread", you're probably doing it wrong.  If you do any threading at all, you should be using the stuff in java.util.concurrent at least.
Offline Varkas
« Reply #17 - Posted 2013-01-14 22:42:33 »

The processor  began to warm and in linux the game was very slow.

The more processing units of the processor you use, the more heat will be produced. A single thread can only use one processing unit (ALU, FPU) at a time, and modern processors have several of them. If you use more threads, usually more of the units will be used and more heat will be produced.

Slowness on Linux can have many causes, bad threading should affect all systems equally, though.

if (error) throw new Brick(); // Blog (german): http://gedankenweber.wordpress.com
Offline 002-Sy

Senior Newbie





« Reply #18 - Posted 2013-01-15 07:07:07 »

Assuming that only one thread is used.
My concern is about the speed of the game and if this problem can also be due to the loading of images, even with the buffer should have no problems. Undecided

About the processor, mine is a dual core,
but I prefer the game to work well with computers obsolete. Clueless
Offline Roquen
« Reply #19 - Posted 2013-01-15 08:45:07 »

Don't worry about things like this in advance.  With practice you'll start to be able to have a feel for things which will be a performance concern.
Offline Varkas
« Reply #20 - Posted 2013-01-15 09:52:45 »

Assuming that only one thread is used.
My concern is about the speed of the game

For ages, home computers had only one CPU/core and in those time almost all games only used one thread. They still ran well.

Even with a single thread you have more processing power at your hand on modern computers than all the game designers befeore had.

if (error) throw new Brick(); // Blog (german): http://gedankenweber.wordpress.com
Offline Roquen
« Reply #21 - Posted 2013-01-15 11:45:26 »

This one thread thing keeps getting repeated.  Statistically very few games (since the 90s) have used one thread...other than embedded devices which would/will use an interrupt handlers to perform equivalent tasks.  It very hard to get exact timings down other than on fixed hardware.  The classic big issue here is input/output devices...notably keeping the sound output buffer filled.  Using a language like java gives one a distorted view because you are multi-threaded...you're just not explicitly creating more then one and the other threads are semi-hidden behind the scenes by the provided libraries.
Offline jonjava
« Reply #22 - Posted 2013-01-15 14:32:23 »

@Roquen
I can't really make sense of what you're trying to say.

Looking at the OP's post the most useful answer here is to use a single Thread.

Offline Roquen
« Reply #23 - Posted 2013-01-15 15:36:40 »

I fully agree and said as much.  But what I'm otherwise saying is let's not propagate misinformation.
Offline Varkas
« Reply #24 - Posted 2013-01-16 14:14:53 »

But what I'm otherwise saying is let's not propagate misinformation.

I didn't intend to spread misinformation. And I'm fairly sure that until Windows games came up, there were almost no multi-threaded games.

An interrupt handler, although enabling quasi-concurrency in a program, is not a thread in my book. Maybe we just disagree on the terminology. Interrupt handlers were quite standard in the games.

if (error) throw new Brick(); // Blog (german): http://gedankenweber.wordpress.com
Offline Roquen
« Reply #25 - Posted 2013-01-16 15:41:05 »

The move from a non-OS (MS-DOS...was pretty much a binary loader) to a multi-process, preemptive multitasking OS is only part of the picture.  DOS didn't have threads, so there you go (actually you could with one of the various DOS-extenders) 

The growing gap between CPU <-> FSB/Northbridge & Southbridge components is a biggy.  One of the big early reasons for graphics cards to start adding computation functionality was to deal with pushing every increase amounts of data over a slow communication channel...the fact that you could do ever increasingly cool stuff was a bonus.

The bottom line is that modernish CPUs stall all the time: cache-miss? branch misprediction? data dependency?  And these are just examples of short pauses.

Bottom line, given three machines all equal, except some hypothetical intel CPU:
A) 1 core @ 8.8Gz without HyperThreading
B) 4 cores @ 2.2Gz without HyperThreading
C) 4 cores @ 2.0Gz with HyperThreading

No question:  I'd take C before B and B before A.

Threads, pico-threads/fibers/green-threads & interrupt handlers are all different, but fulfill a similar need...I didn't intend to imply otherwise.
Offline Jimmt
« League of Dukes »

JGO Kernel


Medals: 136
Projects: 4
Exp: 3 years



« Reply #26 - Posted 2013-01-16 16:44:48 »

And that's why I hate it when people measure computer speed by GHz and solely GHz...
Online theagentd
« Reply #27 - Posted 2013-01-16 19:59:17 »

Bottom line, given three machines all equal, except some hypothetical intel CPU:
A) 1 core @ 8.8Gz without HyperThreading
B) 4 cores @ 2.2Gz without HyperThreading
C) 4 cores @ 2.0Gz with HyperThreading

No question:  I'd take C before B and B before A.

To back this up: I benchmarked my own threaded ball physics test on an i7 860 quad core CPU at 3.52GHz, turbo disabled with hyperthreading.

1 thread: 110 FPS.  1x scaling
4 threads: 356 FPS. 3.24x scaling
8 threads: 478 FPS. 4.35x scaling

Myomyomyo.
Offline 002-Sy

Senior Newbie





« Reply #28 - Posted 2013-01-17 05:25:52 »

Each computer could be updated more quickly than other.

which is better, a Thread or a Timer to measure seconds and so make a good animation,stopwatch, etc...?
Offline Roquen
« Reply #29 - Posted 2013-01-17 09:08:25 »

If you want accurate "wall-clock" (real) timing (ignoring any pausing mechanism) then simply do something like:
1  
public static final long startTime = System.nanoTime();


Example:
1  
2  
3  
4  
public static final double getSecondsSinceLaunch()
{
   return (System.nanoTime() - startTime) * (1.0/1.0e9);
}


EDIT: changed example from singles to doubles so I don't have to bother with a precision discussion. Smiley
Pages: [1] 2
  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.

theagentd (16 views)
2014-10-25 15:46:29

Longarmx (52 views)
2014-10-17 03:59:02

Norakomi (45 views)
2014-10-16 15:22:06

Norakomi (34 views)
2014-10-16 15:20:20

lcass (39 views)
2014-10-15 16:18:58

TehJavaDev (68 views)
2014-10-14 00:39:48

TehJavaDev (68 views)
2014-10-14 00:35:47

TehJavaDev (60 views)
2014-10-14 00:32:37

BurntPizza (74 views)
2014-10-11 23:24:42

BurntPizza (45 views)
2014-10-11 23:10:45
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

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