Sound limit in DinkHD versus YOD
Just noticed something in which sounds stop playing in DinkHD, but are still all there in YOD.
Not sure why, and I've tried commenting out the last three sounds I've added - I now have a total of 80 - but the sword hit sound FX stops playing after a little while, as do some other sounds.
This sword hit is a new sound FX and is at 44100 Hz, 16-bit stereo - as are all the new sounds I'm adding, and I suspect that DinkHD isn't handling this amount, although YOD seems fine.
Not sure why, and I've tried commenting out the last three sounds I've added - I now have a total of 80 - but the sword hit sound FX stops playing after a little while, as do some other sounds.
This sword hit is a new sound FX and is at 44100 Hz, 16-bit stereo - as are all the new sounds I'm adding, and I suspect that DinkHD isn't handling this amount, although YOD seems fine.
that's weird because i had a similar bug when playing the disciple on yeoldedink (who knows which version at this point and maybe its fixed now) where, in the snowy area, the sounds would slowly die out one by one until the weather sound effect was the last one...then also died. eventually, this would lead to a crash, so you'd have to reload to fix the sound.
only thing is, once you did load, every single sound effect that should've played all play at the same time and blow out your speakers.
this was also on steam deck, so who knows what extra layer of issues that brings, running on a custom linux distro.
only thing is, once you did load, every single sound effect that should've played all play at the same time and blow out your speakers.
this was also on steam deck, so who knows what extra layer of issues that brings, running on a custom linux distro.
Indeed, it's an issue with sounds set to loop/survive where the d-mod author hasn't bothered to kill off the existing looping sound meaning that the old ones play forever which eventually eats up all available audio channels. I'm guessing the script for it was nabbed from Cycles of Evil which does the same thing if you traverse too many screens early on. The audio system is supposed to intelligently cull old sounds when it hits that limit and then play all the more recent ones as channels becomes available. I haven't fixed it yet, but it's the same across all operating systems.
I don't know what's causing SimonK's issue however. All I can think of would be to see if converting it to Ogg Vorbis changes anything.
I don't know what's causing SimonK's issue however. All I can think of would be to see if converting it to Ogg Vorbis changes anything.
The majority of my new sounds are .ogg already. I do have some that are .wav files, so I might try converting those to ogg. The original game sounds are still in their original format, bit rate, Hz values.
What are the available audio channels in DinkHD versus YOD?
I saw something in YOD about active voices, is that something else?
What are the available audio channels in DinkHD versus YOD?
I saw something in YOD about active voices, is that something else?
That's the one. In yedink, it is possible to have up to 64 channels of concurrent audio, not to be confused with yedink.ini's setting where it's also possible to set "channels" to 6 if you have a 5.1 speaker system, which is altogether separate. All other engine variants only support up to 20 concurrent sfx channels.
Okay, I've converted all the sound files back to mono to see what effect that would have, and it seems to have resolved the sound going missing in DinkHD, sometimes... Which makes me wonder if stereo files are considered two channels by the engine, that way the 20 slots get filled up quickly perhaps?
I think my problem is a tweaked dam-fire script that works somewhat like acid rain from the original game, in that it creates a stationary missile sprite out of the sprite it just hit so that if Dink or another sprite touches the burning fire they get hurt - and I've set an attack_hit_sound to this missile_target... which I think is the problem, as if I comment out that line, the problem seems to have gone, perhaps the multiple calls are filling up the slots. Unfortunately it plays the default attack sound of a punch whenever Dink touches it, which didn't used to happen with acid rain, so time to take another look at this whole thing.
EDIT
So, attaching a new script to the missile_target sprite seems to have resolved this, without causing the annoying punching sound, and all the new script has is a main procedure with a commented out line.
I think my problem is a tweaked dam-fire script that works somewhat like acid rain from the original game, in that it creates a stationary missile sprite out of the sprite it just hit so that if Dink or another sprite touches the burning fire they get hurt - and I've set an attack_hit_sound to this missile_target... which I think is the problem, as if I comment out that line, the problem seems to have gone, perhaps the multiple calls are filling up the slots. Unfortunately it plays the default attack sound of a punch whenever Dink touches it, which didn't used to happen with acid rain, so time to take another look at this whole thing.
EDIT
So, attaching a new script to the missile_target sprite seems to have resolved this, without causing the annoying punching sound, and all the new script has is a main procedure with a commented out line.
Looking through how missile_target works;
If a missile hits a sprite, and that destination sprite is set hard and has a script, missile_target will be set to 1 along with the enemy_sprite var. Then, if the missile sprite has a script, missile_target is set to the destination sprite, with enemy_sprite var set to 1 (player sprite), and then damage() is run in the missile script if it exists. If damage() runs, the default thwack, or a sprite's attack hit sound will not be played and the missile sprite won't be culled.
If the destination sprite is not set hard, missile_target will be set to zero, but the rest will be as above in terms of attack sounds and culling of missile sprite.
There's some more to it but I can't be bothered unravelling it right now. The main take-away is that a missile with a script that runs damage() prevents sprite attack hit sounds from being played, and that missile_target is often set to 1 or 0, and doesn't necessarily represent the most recent sprite on the receiving end of a missile.
If a missile hits a sprite, and that destination sprite is set hard and has a script, missile_target will be set to 1 along with the enemy_sprite var. Then, if the missile sprite has a script, missile_target is set to the destination sprite, with enemy_sprite var set to 1 (player sprite), and then damage() is run in the missile script if it exists. If damage() runs, the default thwack, or a sprite's attack hit sound will not be played and the missile sprite won't be culled.
If the destination sprite is not set hard, missile_target will be set to zero, but the rest will be as above in terms of attack sounds and culling of missile sprite.
There's some more to it but I can't be bothered unravelling it right now. The main take-away is that a missile with a script that runs damage() prevents sprite attack hit sounds from being played, and that missile_target is often set to 1 or 0, and doesn't necessarily represent the most recent sprite on the receiving end of a missile.
