Re: Ruby or C++ - real-time sound editing
Then, assuming your sounds are big enough, you need to write your own streaming system. It doesn't matter whether you mean 4 GB free or 4 GB total. Most of the people here do not have 4 GB of ram. If you want people to play your game, you need to aim for 2 at most, but really I'd aim for 1.
OpenAL buffers can be queued, and therefore you can do it. I've done it in the past. It's not even that difficult. Your problem is that ruby is just about as far from gaming as you can possibly get, so yes, you will need to do a lot of this yourself. If your OpenAL wrapper doesn't support separating sources and buffers, then you're screwed and there's almost nothing you can do for large sounds. OpenAL itself separates the concepts, but some bindings make it "easier" by exposing them together.
You should also convert anything meant to be played through a positioned source to mono. OpenAL
will use half as much ram for mono sounds versus stereo ones. For panned sources, OpenAL will usually just crush the stereo sound at runtime; since the buffers can't be shared, however, the buffer is still holding twice as much data. If you're using stereo sounds with panned sources, you'll also sometimes hit other bugs. I've seen some implementations of OpenAL only use the first channel of the buffer instead of squashing it for you.
Literally nothing else in this community comes close to using as much ram as you're using. As I understand it, your game is commercial. If your game requires this much ram, then I doubt many people are going to buy it from you. If you are going to sell your game, then buy FMod and save yourself the trouble, because OpenAL isn't really going to give anyone HRTF anyway, not unless they're advanced enough users to edit an ini or you're using OpenALSoft explicitly and your wrap
per supports forcing it to turn on.
Look at your map format. If the problem occurs when you load maps, then maybe it's not even sounds at all. You're saying that it's not a problem until you load a map, maybe your array is horribly inefficient. Languages like Python and Ruby are bad at 2D arrays, so you can usually save a lot by wrapping it in a class that uses a list or the equivalent and does a few basic calculations to find the tile or whatever. This can cut the overhead of map data in half: you are no longer storing the keys, and the keys can take as much ram as the values. Assuming your tiles aren't integers, you can also deduplicate them: create each unique type of tile only once and then reuse the instance over and over.
I'm not sure why you're fixated on sound. Create a test program. Load every single sound in the entire game. See how much ram it's using. Convert every sound in the e
ntire game to .wav, see how much hard drive space it takes. If these numbers are not close to each other or off by approximately a factor of two or four, then you get to blame your OpenAL bindings for introducing a ton of overhead. If it's reasonable, then you need to look elsewhere for other problems. But you should benchmark everything separately at this point and find out what bit of code is actually causing the problem. I would have to try very hard to have enough sounds that they'd actually take up more than a GB of ram. Swamp stops well short of this point and has more sounds than anything I've ever seen. People have full-fledged, long RPGs working on the iPhone with huge 3D models and fully acted cutscenes and all that. I wouldn't be surprised if all the work you want to do to optimize your sound system comes down to almost nothing in the grand scheme. Better to find out for absolute certainty now inste
ad of in 3 weeks, because this really sounds like it may not be the problem you think it is.
_______________________________________________ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
