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?

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?

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

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.

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 coresas it already happens of course, just actually efficient using extra libraries and that sort of thing...

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.

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?

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.

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.

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.

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