Java-Gaming.org Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (804)
Games in Android Showcase (239)
games submitted by our members
Games in WIP (868)
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 3
  ignore  |  Print  
  Threads, games and running on all CPU's  (Read 20254 times)
0 Members and 1 Guest are viewing this topic.
Offline mike_bike_kite
« Posted 2015-09-19 09:31:19 »

I'm currently creating a game where the player flies above a raging sea. The sea is a big part of the game so I'm trying to simulate it all (just in 2D) and have realistic waves etc. There's also a fair amount of particles flying about that need to be accounted for. It's just single threaded at the moment but runs fine (so far) on a fast processor (i5-3570K) but I'm pretty sure it will get unstuck on older processors. The obvious solution is to use separate threads but older, slower processors either have one or two cores so it seemed pointless going for too many threads.

Possible threads might be:
  • thread to play the game
  • thread to handle the sea, waves, splashes, general collisions
  • optional thread for sound?
  • thread to do initialisation and read/write high scores to the web

Would I do best with static arrays for those bits that are used by more than one thread? any other opinions?

Mike

Arcade swarm
Board Chess - Checkers - Othello
Offline theagentd
« Reply #1 - Posted 2015-09-19 10:06:46 »

Giving individual parts of the game (physics, rendering, input, particles, etc) their own thread sounds nice in theory, but usually doesn't improve much as the workload for each thread is very unbalanced, and it doesn't scale well with more cores than you have tasks. The best solution is almost always to use an embarrassingly parallel algorithm and split up the workload between N threads, where N=Runtime.getRuntime().availableProcessors(). I personally dislike static variables. To actually get good scaling you need to avoid all synchronization, which means that your threads should do work that doesn't write to memory shared with other threads.

Examples of things that are threadable for an almost linear increase in performance if coded right (these are pretty meaningless to thread unless you have more than 1 core):
 - Particle physics simulations. Very easy if particles don't interact with each other.
 - Physics/collision detection. Requires some clever tricks and you may need to implement a less effective algorithm that however scales much better with the number of threads.
 - AI, assuming each unit makes its own decisions without any coordination with other objects.
 - Skeleton animation.



Things that can be threaded not for performance but to maintain responsitivity/quality regardless of core count:
 - Network code, to avoid blocking the main thread, although there are non-blocking ways of handling networking.
 - Sound playing should always be done from a different thread to prevent stuttering in case the game runs slowly and to prevent the main thread from getting stuck loading a file from disk during gameplay.


Myomyomyo.
Offline Catharsis

JGO Ninja


Medals: 76
Projects: 1
Exp: 21 years


TyphonRT rocks!


« Reply #2 - Posted 2015-09-19 10:20:06 »

What's your current organization like for your data?

Are you modeling things w/ OOP for the "sea, waves, splashes, general collisions"?

If yes to the above then restructuring things to a more DOD (data oriented design) ditching OOP may give you a lot more performance. IE primitive arrays of data.

You mention "static arrays for those bits". That kind of connotes that you might already be organizing things by primitive arrays of data.

If memory is not a problem a copy of the relevant data per worker thread and splitting it up for data to potentially be processed by multiple threads is possible. Using a simple ArrayBlockingQueue (other options available under java.util.concurrent) to transfer data between threads can be fine because likely whatever processing that is occurring in worker threads is heavier than any synchronization aspects of the concurrent data structure used.

You can roll your own system with an Executor or you could even use fork / join in your main render thread. See this JGO thread:
http://www.java-gaming.org/topics/4-or-more-threads-in-render-loop/34454/view.html

Check out the TyphonRT Video Suite:
http://www.typhonvideo.com/

Founder & Principal Architect; TyphonRT, Inc.
http://www.typhonrt.org/
http://www.egrsoftware.com/
https://plus.google.com/u/0/+MichaelLeahy/
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline nsigma
« Reply #3 - Posted 2015-09-19 11:05:28 »

The best solution is almost always to use an embarrassingly parallel algorithm and split up the workload between N threads, where N=Runtime.getRuntime().availableProcessors().

My instinct (based on no hard evidence whatsoever  Wink ) would be to go with maximum N-1.  There are going to be lots of other things going on you don't directly control, OS stuff, VM stuff (GC, JIT?), audio playback, etc.  Some (most?) of those are going to have priorities higher than your threads.

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline Roquen

JGO Kernel


Medals: 518



« Reply #4 - Posted 2015-09-19 11:06:54 »

note: availableProcessors is the number of virtual CPUs.
Offline theagentd
« Reply #5 - Posted 2015-09-19 11:55:42 »

The best solution is almost always to use an embarrassingly parallel algorithm and split up the workload between N threads, where N=Runtime.getRuntime().availableProcessors().

My instinct (based on no hard evidence whatsoever  Wink ) would be to go with maximum N-1.  There are going to be lots of other things going on you don't directly control, OS stuff, VM stuff (GC, JIT?), audio playback, etc.  Some (most?) of those are going to have priorities higher than your threads.
If you've coded the OpenGL parts correctly the driver will use a second thread to actually process OpenGL commands in so the main thread isn't blocked for too long. Even with that thread, sound threads etc, it is faster to use all processors in my experience. Sound threads should already be running at a high priority to prevent stuttering, and they'll spend most of their time waiting for the harddrive or idling with full buffers.

note: availableProcessors is the number of virtual CPUs.
Your point being? Why would you not want to run your code on all logical CPU cores?

Myomyomyo.
Offline nsigma
« Reply #6 - Posted 2015-09-19 17:56:44 »

If you've coded the OpenGL parts correctly the driver will use a second thread to actually process OpenGL commands in so the main thread isn't blocked for too long. Even with that thread, sound threads etc, it is faster to use all processors in my experience.

Like I said, instinctive thought!   Wink  Still, be interesting to measure that in terms of throughput and latency / response time.

Sound threads should already be running at a high priority to prevent stuttering, and they'll spend most of their time waiting for the harddrive or idling with full buffers.

What dull sound threads!   Grin  https://youtu.be/lK94qu1iObo

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline Roquen

JGO Kernel


Medals: 518



« Reply #7 - Posted 2015-09-19 18:03:48 »

note: availableProcessors is the number of virtual CPUs.
Your point being? Why would you not want to run your code on all logical CPU cores?
There's quite a difference between say: 2 full cores with hyperthreading vs. 4 full cores without hyperthreading.  Ideally you want both pieces of information.
Offline KaiHH

JGO Kernel


Medals: 796



« Reply #8 - Posted 2015-09-19 18:54:01 »

Ideally you want both pieces of information.
True. Could do a JNI library providing that information using libcpuid.
I just test-built it under Windows x86 and x86-64 flawlessly.
Ideally, would do without any third-party library, and under Windows there is at least GetLogicalProcessorInformation, however apparently no such easy equivalent under Linux.
Anyone interested?

EDIT: For anyone wanting to try it out under Windows: https://github.com/httpdigest/jlibcpuid
Offline Spasi
« Reply #9 - Posted 2015-09-19 19:39:15 »

I will be adding hwloc bindings to LWJGL soon.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Roquen

JGO Kernel


Medals: 518



« Reply #10 - Posted 2015-09-19 20:19:47 »

If I remember correctly that has performance counter reading and a bunch of other good stuff.
Offline ags1

JGO Kernel


Medals: 367
Projects: 7


Make code not war!


« Reply #11 - Posted 2015-09-19 20:44:02 »

From my experience of benchmarking, I found that going for more threads than processors gave higher and more reliable performance on windows, but the "extra" threads hurt performance slightly on linux. For example:

http://www.headline-benchmark.com/results/75cd37e4-1ebb-413d-aaa6-7defd480c05b/39377a27-a0af-4245-8b11-a0cf78202cf5

See how the performance is spotty until a large number of threads is being used. It seems the Windows scheduler often dumps threads from the same application onto the same processor...

Offline theagentd
« Reply #12 - Posted 2015-09-19 23:27:38 »

There's quite a difference between say: 2 full cores with hyperthreading vs. 4 full cores without hyperthreading.  Ideally you want both pieces of information.
My last try: Why? In what situation would you want to treat those differently?

Myomyomyo.
Offline nsigma
« Reply #13 - Posted 2015-09-20 12:29:39 »

There's quite a difference between say: 2 full cores with hyperthreading vs. 4 full cores without hyperthreading.  Ideally you want both pieces of information.
My last try: Why? In what situation would you want to treat those differently?

My guess would be based on what I said above - throughput vs latency.  I know various low-latency / soft-realtime audio projects, such as JACK (for which I wrote the Java bindings) recommend switching off hyperthreading in the BIOS.  We won't talk about their opinions on me using a garbage collecting VM to bind to JACK ...  Wink  Interesting Googling gaming, latency and hyperthreading - some similar opinions expressed.

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline mike_bike_kite
« Reply #14 - Posted 2015-09-20 19:35:53 »

[2 full cores with hyperthreading vs. 4 full cores without hyperthreading]In what situation would you want to treat those differently?
HT is different to having a separate core. The main reason why they're different is that full use of HT can only be made if you have relatively little code and a lot of parallel data to process. That's why it's more suited to video and audio work assuming the code is suitably written. In most games it's far better to have a separate core to having HT and this show's in most benchmarks where performance is similar between Intel i5's (4 core 4 threads) and i7's (4 core 8 threads). If HT can't be used by a game then it's important for the game to know how many real processors it has rather than virtual processors.

That's not to say all cores are equal. Intel chips have been better than AMD since Sandybridge and AMD looks unlikely to catch up any time soon. A 4 core i5 will usually beat an 8 core FX chip - I've also seen a budget 2 core G3258 outperform the FX chips. AMD chips are good value though which is why people go for them. The big problem with having more cores is that they generate more heat so you need to run them slower. The other problem for AMD is that their FX chips shares certain components (ie floating point, instruction decoding) between each pair of cores so you're effectively running half as many cores as they state.

So is it important to know the difference between HT and real cores? certainly not to me.

Mike

Arcade swarm
Board Chess - Checkers - Othello
Offline BurntPizza

« JGO Bitwise Duke »


Medals: 486
Exp: 7 years



« Reply #15 - Posted 2015-09-20 19:41:07 »

I'm looking forward to AMD's Zen, which should be interesting; it has an equivalent of hyperthreading among other substantial improvements.
Offline theagentd
« Reply #16 - Posted 2015-09-20 20:14:24 »

HT is different to having a separate core. The main reason why they're different is that full use of HT can only be made if you have relatively little code and a lot of parallel data to process. That's why it's more suited to video and audio work assuming the code is suitably written. In most games it's far better to have a separate core to having HT and this show's in most benchmarks where performance is similar between Intel i5's (4 core 4 threads) and i7's (4 core 8 threads). If HT can't be used by a game then it's important for the game to know how many real processors it has rather than virtual processors.

That's not to say all cores are equal. Intel chips have been better than AMD since Sandybridge and AMD looks unlikely to catch up any time soon. A 4 core i5 will usually beat an 8 core FX chip - I've also seen a budget 2 core G3258 outperform the FX chips. AMD chips are good value though which is why people go for them. The big problem with having more cores is that they generate more heat so you need to run them slower. The other problem for AMD is that their FX chips shares certain components (ie floating point, instruction decoding) between each pair of cores so you're effectively running half as many cores as they state.

So is it important to know the difference between HT and real cores? certainly not to me.

Mike
I know all that. I've done extensive benchmarking with Hyperthreading and have personally written code that gets 6.5x scaling on a hyperthreaded quad core. What I don't know is why you would NOT want to use Hyperthreading if it's available. Hyperthreading especially helps Java programs as we don't have the same control over memory as C has. Let me rephrase the question: Why would I care if the cores are logical or physical? Why should that change the behavior of my program?

Myomyomyo.
Offline mike_bike_kite
« Reply #17 - Posted 2015-09-20 20:34:00 »

I know all that. I've done extensive benchmarking with Hyperthreading and have personally written code that gets 6.5x scaling on a hyperthreaded quad core. What I don't know is why you would NOT want to use Hyperthreading if it's available. Hyperthreading especially helps Java programs as we don't have the same control over memory as C has. Let me rephrase the question: Why would I care if the cores are logical or physical? Why should that change the behavior of my program?
The programmer is trying to find out how many cores are available but is being told how many threads are available. If your program can use a new threads as easily as it can a core then it doesn't matter ie for most video processing, audio processing and your program. Most games don't benefit from HT so the program is being told misleading info from the call ie twice as many cores as there really is. If you then kick off additional processes to make use of those "cores" then the processor would have to swap those processes in and out. This may not be a huge overhead but it is an overhead.

Arcade swarm
Board Chess - Checkers - Othello
Offline Roquen

JGO Kernel


Medals: 518



« Reply #18 - Posted 2015-09-20 20:46:56 »

The last time I did anything heavy in this area was ~5-6 years ago on 4 execution port hardware.  What I was seeing in my use-cases was a hyperthreaded core would hit around .10-.15 the computation throughput of a full core.  In some specialize cases which involved heavy tweaking it could be bumped up to around .30.  These numbers are more or less in line with what others were seeing at the same time.

I have no specific expectation about how these number might look on newer 6 execution port hardware...too many variables, but as a guess it's probably a bit higher.  So attempting to develop a scaling scheme where you don't know if the cores are all full or if half are virtual sucks because it's a huge difference in expected computational power.  Of course I'm not blowing off adaptive scaling.  Perhaps of more interest is that in the hyperthreaded case I switched to using thread affinities which helped in that case and blinding doing the same hurt in all full core case.

But really I don't understand your point.  I'm saying that having more (and accurate) information is a better situation...even if any individual never makes use of it.
Offline theagentd
« Reply #19 - Posted 2015-09-20 21:21:23 »

The programmer is trying to find out how many cores are available but is being told how many threads are available. If your program can use a new threads as easily as it can a core then it doesn't matter ie for most video processing, audio processing and your program. Most games don't benefit from HT so the program is being told misleading info from the call ie twice as many cores as there really is. If you then kick off additional processes to make use of those "cores" then the processor would have to swap those processes in and out. This may not be a huge overhead but it is an overhead.
With HT each core can have 2 threads loaded into two different sets of registers at the same time and work on either one of them. One of the main points of HT is to AVOID the overhead of swapping threads. The other is to allow more efficient use of the CPU's hardware since it can sometimes execute two instructions in parallel. That most games don't benefit from HT is a symptom of them not being able to utilize multiple threads efficiently in the first place, something that as far as I know only the Battlefield series does at all, and those games get HUGE wins from HT. My old laptop with a HT dual-core gained around 50% higher framerates from HT as it was CPU limited. the only time Hyperthreading would hurt performance would be if you're thrashing the CPU cache. In those cases doing that from twice as many threads may actually hurt performance, but that very rarely happens if you know what you're doing.

Scaling in WSW:
1  
2  
3  
4  
5  
6  
7  
8  
9  
Only physical cores:
1 core: 12 FPS (1x)
2 cores: 22 FPS (1.83x)
4 cores: 36 FPS (3x)

Using Hyperthreading:
1 core: 15 FPS (1.25x)
2 cores: 27 FPS (2.25x)
4 cores: 43 FPS (3.58x)


The last time I did anything heavy in this area was ~5-6 years ago on 4 execution port hardware.  What I was seeing in my use-cases was a hyperthreaded core would hit around .10-.15 the computation throughput of a full core.  In some specialize cases which involved heavy tweaking it could be bumped up to around .30.  These numbers are more or less in line with what others were seeing at the same time.
In some very specific cases the scaling is far better than that, but on average you're right. HT helps a lot when you have a lot of cache misses or branch prediction failures, and cache misses are much more abundant in Java than in C, so Hyperthreading helps hiding those problems.

If AMD's next architecture will implement a similar technology that could actually do wonders for them, considering their shitty memory controller holds them back so hard. Or it won't. Who knows?

I have no specific expectation about how these number might look on newer 6 execution port hardware...too many variables, but as a guess it's probably a bit higher.  So attempting to develop a scaling scheme where you don't know if the cores are all full or if half are virtual sucks because it's a huge difference in expected computational power.  Of course I'm not blowing off adaptive scaling.  Perhaps of more interest is that in the hyperthreaded case I switched to using thread affinities which helped in that case and blinding doing the same hurt in all full core case.
I'm not entirely sure what you mean, but the thread scheduler knows the difference between virtual and physical cores and prefers physical cores.

But really I don't understand your point.  I'm saying that having more (and accurate) information is a better situation...even if any individual never makes use of it.
We have a name for unused information: useless information. I am asking you because I genuinely can't see when you would ever be able to change anything to take that into consideration.

Myomyomyo.
Offline nsigma
« Reply #20 - Posted 2015-09-21 08:36:46 »

Ideally, would do without any third-party library, and under Windows there is at least GetLogicalProcessorInformation, however apparently no such easy equivalent under Linux.

btw, can't you get that information quite easily on Linux without JNI by just reading and parsing /proc/cpuinfo ?  Quick Google found this which includes a getNumberOfCores() method.

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline Roquen

JGO Kernel


Medals: 518



« Reply #21 - Posted 2015-09-21 08:59:34 »

Quote
cache misses are much more abundant in Java than in C, so Hyperthreading helps hiding those problems.
Well nobody is forcing anyone to program in an OOP style in performance critical code.  Is the extra effort worthwhile is too big a topic to cover in any generalized case as well as being programmer specific.  HT will do well in covering up some of these hiccups.  Also HotSpot does in some situations insert prefetch ops...I've never looked at this point however.

"branch prediction failures": hum..might be wrong here...it's been awhile since I've thought hard about the micro-architectures..but branch misprediction doesn't free any resources for the HT if I have my brain screwed on correctly.  Trying to fit the details of speculative execution, reordering buffers, register renaming, yada-yada-yada into the brain at once for a extended time is hard.

Quote
twice as many threads may actually hurt performance
If having HT enable slows down performance:  Multithreading:  You're doing it completely wrong.

Quote
We have a name for unused information: useless information.
Useless to an individual.  I personally have no interest in topology queries as I'm not interested in multi-socket hardware in Java...someone else might be very interested in having this information.  I'd very much like to know as much as possible about the specific single-socket CPU however...like is population count available.  Probably very few people want to know that...I do.  The same for a fair number opcodes which HotSpot has intrinsics for.

Quote
I'm not entirely sure what you mean,
Assuming you're not talking about not having any expectations about 6 execution port hardware:  If I know that I have N full core vs. N/2 full & N/2 virtual, I'd be likely to choose a different number of worker threads.  And in the HT case I'd try pinning some threads to a virtual core.  Experimentation based on what has worked in the past combined with what I was seeing in some real world use-case at the time in question.

Let me babble a moment about some hypothetical situation.  You have a HT machine, we're modifying the code that it is running on a full core...how does it (on average) impact both the associated HT core and the other full/HT cores in the system.  Of course this is way over simplified...such is writing MT code.

Make an optimization that lowers the computational cost.  If we eliminate a waiting-for-result stall, the HT has less resources and might slow down.  If not and the "mix" of operations is similar (hitting more or less the same execution ports) then the HT is uneffected.  Since our full core is completing computations faster it might be accessing memory faster which might slow down anyone else that also want access to some shared resource (like memory).

Make an optimization that lowers the number of stalls.  The HT has less resources and probably slows down.  If it's a shared resource stall then other cores might speed up if they were in competition.

In some nearly impossible idealized case some optimized code running in a full core leaves virtually no execution units for the associated HT to use and at the same time frees up resources for other cores to allow them to reach peak performance.  So my point is HT cores do not behave the same as full cores.

The HT case where I was pinning was: most threads were more-or-less computation bound, a smaller number of threads were more-or-less memory bound (in comparison).  By pinning the memory bound to HT cores I got better performance because memory stall where being better hidden on average since they were often waiting for a free execution ports to hit.  Of course this is totally use-case specific.  All MT optimization are.
Offline KaiHH

JGO Kernel


Medals: 796



« Reply #22 - Posted 2015-09-21 09:33:13 »

btw, can't you get that information quite easily on Linux without JNI by just reading and parsing /proc/cpuinfo ?  Quick Google found this which includes a getNumberOfCores() method.
Sure, this is possible, thanks! I somewhat always avoid using file I/O in a simple library, though Smiley I would prefer a solution with a system function call.
However, @Spasi's solution with hwloc is really great, we should wait for that. Smiley
Offline nsigma
« Reply #23 - Posted 2015-09-21 11:24:02 »

Sure, this is possible, thanks! I somewhat always avoid using file I/O in a simple library, though Smiley I would prefer a solution with a system function call.

Or we can replace 5 lines of Java with a complex JNI interface to read those files instead!  Tongue  Personally I prefer the way Linux presents this information.

However, @Spasi's solution with hwloc is really great, we should wait for that. Smiley

Absolutely agree with you, since that provides far more information, and I'm generally in favour of libraries that -

  • Work cross-platform
  • Work on the basis of a Somebody Else's Problem field  Wink

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline Roquen

JGO Kernel


Medals: 518



« Reply #24 - Posted 2015-09-21 12:11:38 »

IMO if you have no multi-threaded experience and want to multi-thread a game.  Take your base-line system (a system you actually possess) and say this is the only machine I care about.  Don't try to get fancy and scale stuff to more powerful machine.  Then painfully fumble your way to a system that works.
Offline mike_bike_kite
« Reply #25 - Posted 2015-09-21 13:14:06 »

I have written multi-threaded games before though I was splitting the game by very large chunks. Game play in one thread, initialisation + web interaction etc in the other thread. I was reasonably happy with the results though felt I should of added the sound to another thread as well. My problem is many people who play my sort of games are playing on home built arcade machines with older PC hardware. I suppose if their processor only has one core then I can just accept that it's too old. If it has HT then I don't really have any issues as the processor is likely to be fast enough to run the game on one core.

My current aim is to do something like this:
  • Thread one: game play
  • Thread two: initialisation, web interaction (high scores)
  • Thread three: simulate the sea
  • Thread four: sound

Thread two is very light and mostly is just waiting for stuff to happen. Should I mix in threads 3 and 4 into thread 2? What happens if I have 4 threads running on an old dual core processor? will it be swapping tasks in and out continually or would it all be cached in the processor? I guess I can just try it each possibility but obviously that takes time.

Mike

PS my dev PC (at home) is probably more powerful than most folks so I might need to scale down Smiley

Arcade swarm
Board Chess - Checkers - Othello
Offline nsigma
« Reply #26 - Posted 2015-09-21 13:26:51 »

  • ...
  • Thread four: sound

Thread two is very light and mostly is just waiting for stuff to happen. Should I mix in threads 3 and 4 into thread 2?

Never mix actual sound processing in a thread with anything else.  But that depends what you mean by "sound".  If you just mean sending events to a sound library, then that's probably fine as the library should have a dedicated thread for driving the audio.  OTOH, if you're using a blocking API such as the lower-level bits of JavaSound, then always use a dedicated thread.

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline princec

« JGO Spiffy Duke »


Medals: 1146
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #27 - Posted 2015-09-21 13:42:27 »

Threads in my game code tend to be distributed thusly:

1. Main thread
2. Sound streaming
3. Asynchronous communications (hiscores server, etc)
4*. A small fixed pool of threads (1 per virtual core) for transforming and writing sprite data to buffers and animating emitters and particles

That's as clever as I like to get. You probably don't realise it but the sound API you're using already does fancy threading in the background and so indeed does the GPU. With garbage collection and background compilation from Hotspot going on you're probably making more use of threads than you realise.

4* is really an optional thing that I've done to split a very few parallelizable tasks into equal sized chunks to operate on all cores. For example I needed to write out 20,000 sprites' worth of data per frame, which also involves transforming their vertices on the CPU: it's easily split into 4 identically sized chunks that will all execute in roughly the same time period. Likewise particles all behave in pretty much the same way and so they're easily split into equal sized chunks.

After all the chunks have finished executing there is usually a "gathering" phase in the main thread that performs some operation on the resulting dataset. For example, the particle animation system - after all particles are processed, the gathering phase scans all the particles that were processed and compacts them, returning dead particles back to the particle pool.

Just thought I'd throw in 2p of confusing information Smiley

Cas Smiley


Offline mike_bike_kite
« Reply #28 - Posted 2015-09-22 10:00:09 »

So if I put my sounds into a separate thread, what's the best way of kicking the sounds off? Do I:
  • just call the sound play method from the other thread - I assume this doesn't offer any advantage in having a separate thread.
  • set a variable that says what sound to play and the other thread polls this variable - obviously only plays one sound at a time.
  • would I need to set priorities on sounds so I don't get a little click overriding a large explosion.
  • would I need to queue the sounds to be played and then pull them when ready?
  • some other way?

Also, if I have a relatively slow processor like a Celeron 2955U laptop processor (2 cores, no hyperthreading), should I still have threads 1,2 & 3 in Cas's post + another thread to simulate the sea = 4 threads? I should point out I'm not using any fancy libraries for graphics etc.

Arcade swarm
Board Chess - Checkers - Othello
Offline princec

« JGO Spiffy Duke »


Medals: 1146
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #29 - Posted 2015-09-22 10:50:00 »

You don't put your sounds in a separate thread... (though you might put music in a separate thread, if you're having to stream and decode it from an OGG or MP3 stream). Sound is otherwise already threaded behind the scenes, and you don't need to worry about it. Just tell a sound effect to play and it'll take care of itself, returning from the call instantly.

You can play a realistically unlimited number of simultaneous sound effects on bog standard hardware these days and again, the sound mixer thread takes care of it all for you behind the scene. Just play whatever you like, it'll all be done for you. You might find that you come up against a limit for sound channels - like 64 or something - in which case you might want a sound priority system but that's for you to implement and to be honest I'd be very surprised if you ever needed it.

Now might be the time to use fancy libraries for graphics Smiley Or even not so fancy... you might want to investigate using JavaFX from now on.

You will still need #1 and #3 (#1 obviously, and #3 unless you want your entire game and UI to freeze solid whilst you attempt network communications or any particularly long disk I/O in the middle of the game).

Cas Smiley

Pages: [1] 2 3
  ignore  |  Print  
 
 

 
Riven (581 views)
2019-09-04 15:33:17

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

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

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

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

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

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

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

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

nelsongames (5115 views)
2018-04-24 18:15:36
A NON-ideal modular configuration for Eclipse with JavaFX
by philfrei
2019-12-19 19:35:12

Java Gaming Resources
by philfrei
2019-05-14 16:15:13

Deployment and Packaging
by philfrei
2019-05-08 15:15:36

Deployment and Packaging
by philfrei
2019-05-08 15:13:34

Deployment and Packaging
by philfrei
2019-02-17 20:25:53

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