The Dink Network

I'm not sure that argument number 4 (int active_sprite) actually works

int playsound(int sound_number, int min_speed, int rand_speed_to_add, int active_sprite, bool repeat)

I've tried it in the latest DinkHD and freedink on PQ, with the springers in the purple caves.

If you use any positive integer, no sound, iff you use 0 or a negative number, sound, but it's just blasting out at full volume and not relative to Dink's current position.

Now sp_sound(int sound_bank_num) is working for the most part, with one weird exception, when I leave the cave with the yellow crystal one instance of the sound continues once Dink is in the house after the warp from touching the stairs. If I go out of the house into the village via the door warp, it disappears. Go back inside the house and it is gone.

I've looked via Sprite Replacer for any weird sprites with sound number 50 (the boing.wav) attached and none found, no other sprites with the script that uses this number other than the ones in the cave, so I'm stumped.

looking back through the posts, others in the past have noted the 3D sound placement thing not working.

Anyone got this to work?

If a sound is bound to a sprite with playsound, it will be updated every frame as per the player's position until that sprite is deactivated somehow, or when changing screens upon which it is halted.

Sounds set looping will always be halted upon changing screens unless set to survive. One-shot sounds will continue until they finish.

Invoking sp_sound is equivalent to playsound set looping bound to the specified sprite, unfortunately locked at 22khz playback sampling rate.

Setting the sound parameter for a screen sprite in map.dat is the same as the aforementioned except if the sprite is set to warp in which case the sound will played one-shot upon warping. If the warp has no sound specified, it will play sound slot 7 at 12khz.

The use of positional looping sounds is apparent in the savebots in the base game, as well as one-shot sounds for the pigs and ducks.

As far as I know, it's worked for me everytime. Weird with the sound carrying across to the screen in the yellow crystal. What screen number? I might take a look out of curiosity.

Indeed all of that is true.

And sp_sound is doing the right thing with positional sound and the sound being killed on leaving the screen... except for that one time on screen 131 in PQ. Now I might have something weird going on here that eludes me, but I'm stumped on this.

If I swap out sp_sound() for playsound() in the script, then adding a positive value in the 4th argument seems to stop the sound when using playsound() command, leave it as 0 (or even a negative number) and the sound plays, but is not positional as per the DinkC ref.

Not sure if this is a recent thing, or not.

But there was a post about this issue a number of years back.

If someone can check this using the latest DinkHD, that would be great. I'm trying to eliminate as many annoying bugs as possible from PQ, and am currently in the land of Punz testing the m-rated version.

As it may be unclear to those who stumble upon this thread in the future, for sake of completeness, the "positive value" mentioned as the 4th parameter to playsound() must be a sprite number of a living sprite such as 1 for the player, or current_sprite for the script's sprite as is most common.

In response to the first point about argument 4 in playsound causing sound not to play - I just tested it in DinkHD, it worked for me.

It might be important to note, that repeat sound cannot be set to 1 when a sprite is defined in argument 4, otherwise, no sound will play. Repeat sound only seems to work when argument 4(int active sprite) is 0. I think it's always been this way, but for some reason is not mentioned in the DinkC Ref; I will update the ref to reflect this.

As for the sound glitch on the yellow crystal screen... I couldn't reproduce it on the latest PQ version currently aviailable on the DN, in the latest DinkHD. Although, when the game started I cheat warped to that screen just for the purpose of testing this, not sure if somehow an earlier screen that I didn't go through caused it but I doubt it. I can't hear any continuing spring sound when I enter the house using the stairs on that screen though.

Thanks for looking into this.

So, the positional sound doesn't work if the sound is set to repeat using playsound(), bummer. I guess that's the big difference with sp_sound(). And it is sp_sound() I like... the glitch does go away after two screen changes - warping to the interior of the house, then warping to the village... I'll live with it for now.

Just another day in DinkC/Engine hell for me...

Excuse me gentlemen but what the hell am I reading? sp_sound is defined in the source across all engines as an alias for:

playsound(sound, 22050, 0, sprite, 1)

You can try this yourself with a savebot. Remove the sp_sound line in the stock savebot script and replace it with:

playsound(34, 22050, 0, &current_sprite, 1)

And it should produce the hum that we're all accustomed to in the exact same way. Any divergence from this behaviour is an engine bug, or should be, as the invocation is the same.

Alright I figured it out. The problem is not so much with playsound as it is with the "3d positioning" update function that is run every frame, and is a misnomer anyway. It has a number of conditionals which must be met for a sound to be continually updated, and when those are not met, the sound is halted.

For the sound to be updated, it must be a living sprite, but most importantly/unfortunately, the specified living sprite must have a number other than zero in its own sound slot. This is the sound slot that is assigned in the editor, and that gets updated when running sp_sound, after which playsound is called by the engine.

If the sprite's sound value is set to zero, the sound is immediately halted on the next frame by the update function. You can fudge this by running sp_sound, or assigning a value in the editor that corresponds to an unused sound slot. Therefore the example above with the savebot becomes:

sp_sound(&current_sprite, 99)
playsound(34, 22050, 0, &current_sprite, 1)

Where 99 can be replaced with any blank sound slot. This fools the update function and should make the playsound audible. Apologies for double posting.

Ah, ok. So we weren't losing our mind, and what we were writing was the case hehe

That makes sense though, I thought it should work somehow, good to know about the value required in sound slot, I will update the playsound function in DinkC Ref so anyone else who wonders why a repeating sound on a sprite simply won't work just with playsound only, has the answer.

I'm using every sound number available... all miserly 99, plus reloading others into existing slots as the DMOD progresses, which makes the saving and reloading with the autosaves and quicksaves of DinkHD a little more ... um interesting... alopeciatic... (not even a word...)

You can re-use soundbank numbers too. You can load over the top of them as many times as you want. Just do load_sound again anywhere and load the new sound in.

EDIT: NVM. You already mentioned your doing that lol. I need sleep.

Well, playsound is working fine. It's the positional audio system that 100ms later (it doesn't actually run every frame) goes "No sound for you!". This is why in Sparrowhawk's thread he reports that he hears a small blast of audio that soon cuts out. I don't know why it requires the sprite to have a positive sound value, as it doesn't seem to serve any worthwhile purpose, other than to result in threads like this one.

Turns out that sp_sound doesn't care what value it gets as long as it's greater than zero, and most likely neither does the editor value. Changing 99 in the above example to 999 is fine too.

For sake of completeness, this will most likely crash 1.08 unless you do it properly and load a silent wav into the relevant slot first which presumably must be a real one.

"For sake of completeness, this will most likely crash 1.08 unless you do it properly and load a silent wav into the relevant slot first which presumably must be a real one."

It doesn't crash 1.08, I just tested it. In all Dink engine versions, any positive number given in sp_sound will do.