Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1366303 Posts in 64029 Topics- by 55916 Members - Latest Member: Sideways

September 20, 2019, 03:18:36 PM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperAudioShould all UI-controls have "rollover"-sounds?
Pages: [1]
Print
Author Topic: Should all UI-controls have "rollover"-sounds?  (Read 420 times)
Thaumaturge
Level 10
*****



View Profile WWW
« on: June 14, 2019, 10:40:06 AM »

This is a point of audio-design for my game that I'm rather uncertain of: should every UI-control--buttons, inventory-slots, drop-down-menu items, etc.--have rollover sounds?

When playing with a gamepad, such sounds can add to the feedback of navigating the UI, I feel.

However, when playing with a mouse, rapid movements can result in lots of sounds being triggered, not to mention audio glitches as the sound-clips pile up. (This is especially true with drop-down menus, which can potentially hold lots of entries.)

On the other hand, is it a good idea to have my UI be silent, providing no audio feedback as it's navigated?

Now, perhaps I should have only some of my UI elements produce sounds. If so, however, which ones...?
Logged


Traversal, exploration, puzzles, and combat in a heroic-fantasy setting
Website ~ Twitter
ThemsAllTook
Global Moderator
Level 10
******



View Profile WWW
« Reply #1 on: June 14, 2019, 02:53:38 PM »

My experience has usually been that when it comes to sound effects, more is better. For something like this that would play so frequently, I'd make it extremely short and quiet - just enough to be noticeable. In addition to having a visible rollover state, a little audible click helps to feel out what your mouse is pointing at.
Logged

Thaumaturge
Level 10
*****



View Profile WWW
« Reply #2 on: June 15, 2019, 09:38:20 AM »

Hmm... Well, the sound that I have at the moment is, I think, reasonably quiet and very short (~0.06s, I believe). And what you say does encourage me towards having all UI-controls produce rollover-sounds...

But would the audio-glitching caused by rapid mouse-movements on denser menus (like the resolution drop-down) not be a potential annoyance?
Logged


Traversal, exploration, puzzles, and combat in a heroic-fantasy setting
Website ~ Twitter
ThemsAllTook
Global Moderator
Level 10
******



View Profile WWW
« Reply #3 on: June 15, 2019, 12:24:48 PM »

But would the audio-glitching caused by rapid mouse-movements on denser menus (like the resolution drop-down) not be a potential annoyance?

What does it do? That sounds like a technical problem that should be fixable.
Logged

ProgramGamer
Administrator
Level 10
******


The programmer of games


View Profile
« Reply #4 on: June 17, 2019, 04:22:59 AM »

If playing more than one instance of a sound at once causes audible glitches, you're probably interrupting the previous sound to play the new one. Audio frameworks usually have channel pools or the likes to prevent this sorta stuff, but I'm not sure what you're using so I can't give you more specific advice.
Logged

Thaumaturge
Level 10
*****



View Profile WWW
« Reply #5 on: June 17, 2019, 03:45:23 PM »

What does it do? That sounds like a technical problem that should be fixable.
If playing more than one instance of a sound at once causes audible glitches, you're probably interrupting the previous sound to play the new one. Audio frameworks usually have channel pools or the likes to prevent this sorta stuff, but I'm not sure what you're using so I can't give you more specific advice.

In short, playing a few sounds one over the other isn't a problem, but a quick sweep of the mouse at a decent frame-rate can potentially trigger the roll-over sounds for several objects at once. When this happens, there's a sort of electronic burr that appears. What I imagine is happening is that the engine is running out of channels--but that is just a guess, as audio is not my strong suit.

Here's a short video demonstrating the issue in question. It first shows UI-items being rolled over at a moderate speed, and the sounds being played as expected, then UI items being rolled over swiftly, incurring the glitching.




As to what I'm using, that would be Panda3D, with an OpenAL plugin handling audio. This is all being run under Ubuntu Linux.
Logged


Traversal, exploration, puzzles, and combat in a heroic-fantasy setting
Website ~ Twitter
ThemsAllTook
Global Moderator
Level 10
******



View Profile WWW
« Reply #6 on: June 17, 2019, 05:36:12 PM »

Aha, I hear what you're talking about. Looking at the waveform, I can see that each sound is indeed being interrupted by the one after it. Generating multiple AL sources (probably at least 8, probably not an excessively higher number than that) and cycling through them every time you assign a buffer and call alSourcePlay should fix it right up. I'd probably put in a much longer sound as a placeholder while debugging so you could more easily tell if it's being interrupted without having to listen for a weird buzz or examine the waveform to see what's going on. If you're not calling OpenAL functions directly, I'd imagine whatever API is layered on top of it would have some sort of facility for automatically doing this.
Logged

Thaumaturge
Level 10
*****



View Profile WWW
« Reply #7 on: June 18, 2019, 09:30:24 AM »

Hmm... Inspired by your comment above, I just tried a quick experiment: I swept the mouse quickly over another list of UI-controls that have the same rollover-sound as in the above video. In this case, the sounds seem to overlap, and a look at the wave-form seems to support this--but don't produce that "burr". It looks as bit like sounds can perhaps overlap, but at some range of overlap produce that unpleasant noise.

It is possible, however, that I'm mistaken about the overlap, and misinterpreting the waveform.

Aha, I hear what you're talking about. Looking at the waveform, I can see that each sound is indeed being interrupted by the one after it. Generating multiple AL sources (probably at least 8, probably not an excessively higher number than that) and cycling through them every time you assign a buffer and call alSourcePlay should fix it right up. I'd probably put in a much longer sound as a placeholder while debugging so you could more easily tell if it's being interrupted without having to listen for a weird buzz or examine the waveform to see what's going on. If you're not calling OpenAL functions directly, I'd imagine whatever API is layered on top of it would have some sort of facility for automatically doing this.

The API that I'm using is much higher-level than that! (Indeed, I believe that it's agnostic with regard to the audio-engine backend; I would be using the same functions if I were instead using the FMod plugin.) It's possible that there is access to at least some of that functionality, but that's something to ask after on the Panda3D forum, I think!

And indeed, now that I have some idea of where the problem lies, and that it is indeed a bug and not expected behaviour, I think that I should ask for further help on the Panda3D forum.

Thank you very much for your help, both of you who posted here! It's much appreciated! ^_^
Logged


Traversal, exploration, puzzles, and combat in a heroic-fantasy setting
Website ~ Twitter
ProgramGamer
Administrator
Level 10
******


The programmer of games


View Profile
« Reply #8 on: June 18, 2019, 09:43:05 AM »

Not sure if it helps, but when I added fmod to my game, I forgot to call its update method every frame, which meant that no channels got freed and playing a new sound always interrupted the last sound played. Maybe your API does something similar and you're not calling a function every frame?
Logged

Thaumaturge
Level 10
*****



View Profile WWW
« Reply #9 on: June 18, 2019, 09:56:27 AM »

I'm pretty sure that such things are handled in the background by the engine, in this case. Indeed, I don't think that I've had other such problems with the various sounds present in the game, which suggests to me that, as long as the sounds don't layer over each other too much, the engine's audio channels aren't overwhelmed.

[edit] I just double-checked the engine's manual, and it seems that such a method is available, but is only required when running a game via an interactive prompt. The manual seems to indicate that under normal usage the relevant "update" method is called each frame in the background.
Logged


Traversal, exploration, puzzles, and combat in a heroic-fantasy setting
Website ~ Twitter
fluffrabbit
Level 2
**



View Profile WWW
« Reply #10 on: June 18, 2019, 08:43:47 PM »

On a low level, many audio APIs time to the nearest packet, which is usually 1/60 of a second or longer. At 48 khz with 1024 samples per packet (which is what I'm currently using) the packets are 1/46.875 seconds. If you've got some uber fast gaming monitor, it is possible that multiple sounds are piling up on the same packet at the exact same time. For game sound effects it isn't usually a problem, but maybe you can decrease the packet size a bit.
Logged

Thaumaturge
Level 10
*****



View Profile WWW
« Reply #11 on: June 19, 2019, 09:36:08 AM »

On a low level, many audio APIs time to the nearest packet, which is usually 1/60 of a second or longer. At 48 khz with 1024 samples per packet (which is what I'm currently using) the packets are 1/46.875 seconds. If you've got some uber fast gaming monitor, it is possible that multiple sounds are piling up on the same packet at the exact same time. For game sound effects it isn't usually a problem, but maybe you can decrease the packet size a bit.

Interesting--I wasn't aware of that. Thank you for the information! ^_^

That said, I discovered the source of the problem today, thanks to a poster on the Panda3D forum:

In short, the problem lay with the manner in which the specific type of UI-control shown in the video is constructed. It seems that it was resulting in a single sound-object being assigned to all items in such menus, and thus, I take it, the sound-object being restarted with each new rollover!

(Indeed, this explains why I was hearing this "burr" in some sets of UI-controls and not others: only such menus as shown above are constructed in this way, if I'm not much mistaken.)

Thankfully, the solution was fairly simple: I'm already sub-classing that UI-control class, and overriding the method in which it sets its menu-items. This means that I can simply assign separate audio-objects to each menu-item myself. And indeed, this seems to have solved the problem! ^_^
Logged


Traversal, exploration, puzzles, and combat in a heroic-fantasy setting
Website ~ Twitter
Pages: [1]
Print
Jump to:  

Theme orange-lt created by panic