Sunday, May 20, 2007

A Sound Manager

Today I added a new Sound Manager into the engine. I got a lot of the base code from a great Java Game development book (referenced below). The sound manager works by creating a pool of threads (16 in total) and when a sound is parsed to the manager it sends it off to the pool to be queued waiting for a free thread to execute the sound on. The manager also makes use of a Sound object class that allows you to store the sound information as an object making it highly reusable and eliminating the need to read the file more than once.

Whilst testing the new sound manager, I discovered that the sounds I was using all had different bitrates and sample rates, some were 22050Hz while others were 44100Hz. This was causing a problem because the manager only allows you to use only one audio format, so I downloaded a program called "EArt Audio Converter" it is designed to convert all sorts of file types (mp3, wav, etc) from one type to another. In this instance I only wanted to use it to convert my wav files into a new wav audio format and make them all the same. The version I used was only the trial version, and according to the interface it would only convert 50% of the file, but after converting a couple of files it seemed like it was doing the whole thing, maybe the files are to small to be cut short *shrug*.

Eventually I got all the sound files I wanted to test out to use 44100Hz at 16bit stereo, its pretty high quality I think, but I don't particularly care at the moment. So any of you developers out their, just remember that you have to convert all your sound wav's to this format or it wont work.

Lastly, at the beginning of the project I noticed that the original GLDisplay code used an FPSAnimator which is apart of the JOGL library. The FPSAnimator acts like a thread that executes a set of OpenGL functions which can be used to render things to the screen, their is another one just like it called Animator. Both of these objects do the same thing by making the java source code execute the OpenGL functions, but with the expection that the FPSAnimator is specifically designed to restrict the frame rate to a desired rate, the rate is not guaranteed but the FPSAnimator does try its best to limit the frame rate. The Animator is specifically designed to run at the maximum amount of frames per second, and this can be achieved by turning v-sync off (at the beginning of the project I was getting 3000 frames per second). Anyway, so at the beginning of the project I replaced the FPSAnimator with the a normal Animator because for some unknown reason it was acting strange and rather than limiting to 60 frames per second it was averaging about 40. It was only recently after doing some testing at uni that I discovered that having a faster frame rate increases the speed of gameplay and possibly makes it harder to play than we intended. So to counter this I put the FPSAnimator back in, and played around with some of the settings and worked out that by telling it to schedule at a fixed rate eliminated the early problems I had. It may have also improved the performance of the engine because the FPSAnimator attempts to avoid using all the CPU time.