Revising Clientside Sound Sources

edited 2009 Dec 31 in Developers
<i>This post was originally made by <b>danij</b> on the dengDevs blog. It was posted under the categories: Beta 7, Engine, Version 2.0.</i>

As you know I am in the process of refactoring the runtime map representation and am currently in the middle of a total overhaul of Sector Plane management. In the process I couldn't help but notice that the handling of client-side sound sources (e.g., sounds emitted from mobjs, sectors, polyobjs etc) is really rather cumbersome...

As we support positional audio obviously that requires a set of coordinates for each sound source so that they can be positioned correctly in the soundscape.

However what I don't understand is why the client needs to know which object the sound was emitted by. Surely all the client needs to know is the sound id, its position in the world and how many times it should repeat/loop?

Presently the Doomsday net protocol requires that an origin be specified (mobj/sector/polyobj/etc...) in order for positional audio to work else the sound will be played as if emitted by the listener.

This approach seems unnecessarily complicated and the present protocol does not provide any means to play a positional sound from a new origin type without modification to the protocol itself (albeit a relatively simple introduction of a new delta type).

My opinion is that a much simpler scheme would be preferable with only one delta type for sounds but which may include (optional) arguments for world position etc.

I believe this is something that we should be addressing for beta7

Comments

  • I haven't yet reached a point where I've had the opportunity to consider how sounds should be handled in the unified networking scheme, but my initial idea was that the origin would be represented by an instance of the Object class, which is the base class for all Thinkers. That essentially contains position and momentum information. We will need more than a position for proper 3D sounds as momentum does have an effect as well (doppler). This means that while sounds can be emitted by anything derived from Thinker, also "invisible" Object instances could be used.

    Environmental sounds such as those emitted by sectors, planes, and polyobjects may need a bit of thinking, though, as we should naturally avoid having an extra Object for each of these to act as the "sound origin" mobj like we've had hitherto.
  • Its mainly the sounds emitted by sectors, planes and polyobjects that need some re-thinking though I would prefer if whatever scheme we come up with could be used across the board for everything. Using "invisible" Object instances as the origins for all sounds would simplify the net protocol quite a bit.

    Ideally I would like to remove the sound origin members of Sector, Plane and Polyobj.
Sign In or Register to comment.