questions about the threads. help

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

Please, help

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).

Take a look at clickermonkeys tutorial:

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

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?

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.

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.

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:

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.

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.

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

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.

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…

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.

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.

Only if you’re doing it wrong. It’s rarely expected that computational power is multiples by the number of physical CPUs however.

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.

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? :clue:

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

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.

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.

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. :-\

About the processor, mine is a dual core,
but I prefer the game to work well with computers obsolete. :clue:

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.