Increased sound channels on Actors, revisited

[Nash]

I didn't want to necro the old thread. Arookas, on Discord yesterday, gave some ideas on how to get around the bad parameter design.

1) change internal S_Sound function to separate the flags and channel parameters, if they aren't already

2) change the internal code for A_PlaySound and all existing mod-side functions for 1), but without changing the parameters to said function (just the values it passes to S_Sound)

3) add a new mod-side function with two separate parameters, flags as one and channel number as another allowing you select more than 8 channels(edited)

keep the flags enum starting at the fourth bit, that doesn't matter

looks like right now S_StartSound takes just an int (also bad) for both channel and flags and splits them at the beginning, so 1) would be necessary

just pass in the flags and channel number as separate parameters to S_StartSound, then change all the relevant engine-side code (all the hard-coded sound playing) so the only place that has them both in one value would be A_PlaySound's code
you'd effectively have the

Code: Select all

    chanflags = channel & ~7;
    channel &= 7;

in A_PlaySound instead of S_StartSound

then you'd just make a new actor function to play a sound with these two parameters split

the hardest thing would be deciding what to call the new function, but why have standards for those now lol

What do you think? Could this work?

[Graf Zahl]

You mean deprecating all existing sound functions for ZScript and replacing them with variants that take one additional 'flags' parameter? It's not just A_PlaySound but the entire batch.

[arookas]

The best time to plant a tree is 20 years ago. The next best time is today -- or, in zdoom's case, tomorrow, I guess.

Hardly all sound functions. Most of them are relics that don't take channel or flag parameters, such as A_PlayWeaponSound. Of the ones I could find on the wiki, I saw A_PlaySound, A_StopSound, PlaySound, and PlayActorSound. (If there are any zscript-specific ones or others taking a channel parameter, let me know; I couldn't see any others listed on there.)

A_StopSound is irrelevant since it doesn't take flags, just channel number, allowing it to work as-is with the extra channels. That leaves 3 sound functions, of which you could combine the two ACS ones into one forward-compatible function with features from both of its ancestors. You could likely get by with just two new functions.

I still stand by that the hardest thing would be the names. A_StartSound? Maybe a static actor function? Who knows. But it does definitely seem possible and can be done very cleany -- name withstanding.

Note that I'm not fighting for this feature. I didn't even know this would be turned into a feature suggestion. Just saying an idea I had to get around this problem. Pretty sure there is still something in the bigger picture that hasn't been mentioned that I am missing.

[Graf Zahl]

So, back to this one.

It was always on hold because I never looked into the sound code and always assumed that there were some arrays holding the sound channels which would have to be expanded. Turned out that this had been eliminated long, long ago, and it was "just" separating the flags from the channels. Which amounted to a few hours of adding a new parameter to all sound playing functions in the engine, deprecating S_Sound and A_PlaySound on the script interface (the latter one without a deprecation message due to its widespread use) and replacing them with new S_StartSound and A_StartSound variants.

Now the channel number can be used as what it essentially was all the time - an abstract identifier, not an index, IOW, it can now be any integer value you like - just 0 (i.e. CHAN_AUTO) will remain as it was and pick one of the first 8 channels for compatibility purposes. The old sound functions will also just behave as before and mix channels and flags.

Now all I can do is hope that there wasn't some subtle error that got added...

[Nash]

HOLY SHIT! Thank you!!!

[XLightningStormL]

Wait, can someone ELI5, or at least confirm what I am thinking? Does this mean we now have more than 8 sound channels?

[arookas]

Well worth the wait. I’m excited to see this put to good use. Mad props!

[Nash]

Wait, can someone ELI5, or at least confirm what I am thinking? Does this mean we now have more than 8 sound channels?

Yes... or to be more specific, each actor can play more than 8 sound channels. 4,294,967,294 channels, if I'm reading it right.

Do note that you are still limited by the sound system's total channels, which can be found under the Options -> Sound Options menu.

Also, be mindful of the performance costs of playing sounds, specifically concerning looping sounds - it can get rather expensive.

[Graf Zahl]

The main advantage is not being able to play more sounds at the same time but having to play them without interfering with each other by allocating a dedicated channel for each. Normally I'd say that if one actor needs to play 8 sounds at the same time, something with the design is wrong.

[Marisa the Magician]

I've actually run into that problem multiple times with Doom Tournament / Doomreal. There is so much going on into one player that having 8 channels just wasn't enough for:
1. the player's typical voice sounds for taking damage and whatnot.
2. the player's footstep sounds.
3. sound effects from active inventory items (e.g. damage amplifier) being used.
4. weapon sounds that shouldn't stop each other, therefore needing more channels, twice as many in the case of dual-wieldable weapons (unreal simply had SLOT_None to handle overlapping sounds).
5. pickup sounds playing on the player rather than the item itself like in unreal, which takes over CHAN_ITEM.
6. looping sounds for various things, which are currently handled by spawning separate actors that follow the player (I do this in many other mods too).
7. making sure that if another mod also uses channels 5 through 7, it wouldn't screw with the sounds from my mod (in the end I couldn't do this and just crossed my fingers that it wouldn't happen).

[SanyaWaffles]

Like Marisa I've been finding in development I've been needing more than 8 sound channels, so this will be useful.

[Nash]

Yeah, 8 channels was a little _too_ limiting, I would have settled for something a little higher like say, 16. I do agree that if a single actor needs to play more than 32 or hundreds of sounds simultaneously, something is wrong. And if there will be multiple instances of that actor, something is definitely fucked design-wise. :P

[Player701]

Yes... or to be more specific, each actor can play more than 8 sound channels. 2,147,483,647 channels, if I'm reading it right.

It looks like the channel number is stored as an 8-bit unsigned integer. This can lead to a confusion, considering that the corresponding ZScript argument is of type int. For example, I assigned an arbitrary random value to the channel number in my code, and then spent an hour debugging because IsActorPlayingSound did not seem to work...

[Marisa the Magician]

oh so we have 255 channels instead. Still enough for anyone.

[Nash]

Hmm, that would mean 255 maximum channels per actor, then. My bad. That's still hella plenty though. EDIT: Graf fixed it to be a full signed int so technically you have about 4294967294 channels (-2147483647 to 2147483647).