Argh wrote:1. How does this affect the current COB call to play a sound? I.E., is that COB callout via GET going to be changed, or will it behave like it always has, but now it's referencing a SoundItem? Sorry in advance... I'm using that throughout P.U.R.E., I'd like to know if major problems are going to happen ASAP, obviously.
When you make a COB sound call, it will:
1) check if you have specified a SoundItem with the exact name $x, if yes, play it
2) if no, behave like before (so play a wav, maybe with "sounds/$x.wav" appended)
Argh wrote:2. Name collisions. Does it matter, if the table entry is the same as the name of the file (other than .wav)?
You can do that, and spring will play the Item instead of the wav.
Argh wrote:3. From your answer, I'm guessing that old-skool backwards compatibility will be maintained, by building the table automatically, so that older games do not crash or lack functional sound.
Yes, when not doing anything, you get the same behaviour as before (with the little change that all sounds have Maxconcurrency=16)
Argh wrote:How can we print that file out? That would provide an easy path to utilizing the advanced features for all of us lazy game designers... because I wouldn't have to type out the initial entries by hand. I have... meh, I have 235 sound files in P.U.R.E., a few more in World Builder... and I expect that to grow before RC4 is (finally) released. We're talking hours and hours of labor here, if I have to type it all out by hand.
Anything to help automate it would be... nice. If it's already building this table... just tell me how I'd print it back out with Echo.
I will definitely do something like this, so wait until you edit all by hand. (TODO1)
Argh wrote:Also... if we build a file... it will override the auto-build, correct? Or will that get appended? If so, what happens, when, say, a Weapon calls for a sound?
For clarification: there will be no auto-build table.
If you call for a sound you don't have specified a SoundItem for, it will load the regular wav-file like it has been before, and simply assign default values. It does not matter if you have SoundItems for other sounds.
Argh wrote:Do I need to make sure it's using the new entry, and if I get my initial list built by printing out the table that's auto-generated... if it's appending stuff, just to be safe, it'll be using some new name (i.e., "HugeBoom01" already exists in the game's tables, therefore name HugeBoom.wav with a new entry, "HugeBoom02")?
To keep it simple, the auto-generated (and only spring-internal) names for the SoundItems are the same as their filenames. ANd names need to be unique, if you make another entry with the same name, the old one will be overwritten. (TODO2: print warning / done)
Argh wrote:Also, /Sounds has been supporting multiple directory levels for some time now, just FYI, I'm already using that for Unit replies, etc., so make sure the parser takes that into account, when building the file. You've probably already done all that, but I thought I'd just ask and make sure...
The parser is not interested in directory names. It will generate a SoundItem once you call for a sound from lua, cob, tdf, so it takes the name from you. It doesn't even matter if its in "sounds/", you can specify any place you want.
Argh wrote:4. Can we have a Lua callout to PlaySoundItem(string name, {params})? Pretty please? Then you wouldn't have to hard-code doing stuff like random pitch-shifts... you're probably way ahead of me there, but I thought I'd go ahead and make that a formal request anyhow.
First, lua can already play sounditems. Creating new sound items on the fly in mid-game is not good, because it need to invoke whole lua-parser-stuff. But it will be usefull to create a new SoundItem from a lua-callin (TODO3: lua callin SoundItem generation).
Argh wrote:5. Can we pre-load sounds via a param? Certain things cause a fairly noticeable drive-hit, it'd be really nice to store them in RAM. Not everything, mind you, that would be crazy, just certain things that we want to have immediately available.
Agreed (TODO4 / done).
edit: some sounds are already preloaded. if you type "/debuginfo sound" ingame, you will see the number of SoundItems, SoundSources, SoundBuffers (1 buffer per wav-file) and the size of all buffers currently loaded.
Argh wrote:6. Looping? Pleeeeeeeease? Doing it in COB is fail, sounds cannot often be made to fit very precise framelengths, and doing it in Lua would get veeeeeery expensive and very time-consuming to maintain, because Lua can't read the length (in absolute time) of a soundfile. So we'd have to get that information manually from sound editors, hand-enter it, etc., which seems like a massive bother, when the engine can read that and store it for us. Just askin', man- you've already done more than I was hoping for anyhow, this is a major step up.
Agreed (TODO5 / done).
Random thought 1: much todo, may take some time
Random thought 2: should make some propper documentation somewhere