Net Deltas and Sound Origins

DaniJ

<i>This post was originally made by <b>danij</b> on the dengDevs blog. It was posted under the categories: Engine, Games.</i>

Currently there is only one degenmobj_t per sector which is used for playing all sector based sounds and the z height of these sector sound origins is always 0. The result is that when using 3D sound - sounds emitted from a moving plane will always play at the height of the sound origin as set during level setup.

I've now added two more degenmobjs to each sector (floorsoundorg & ceilingsoundorg). I've now got to update the Net Delta so that the sounds are played from the correct origin client-side.

I can see two options here:

* Implement two new delta types: DT_SECTOR_FLOOR_SOUND & DT_SECTOR_CEILING_SOUND (these would confuse old clients).
OR

* Use the existing DT_SECTOR_SOUND delta type and OR-in additional flags to denote which origin to use (would be backward compatible).

skyjake

Have there been any changes to the network protocol (the format of the deltas and other packets) so far? It would be nice to not break it at this point. So if the new delta data could be sent in a DT_SECTOR_SOUND with some new flags, that should be the best solution.

DaniJ

<blockquote>Have there been any changes to the network protocol (the format of the deltas and other packets) so far?</blockquote>
Not yet but there is other stuff that will need to be added to the packets in some way (surface colour changes, mobj fade targets etc).
<blockquote>
It would be nice to not break it at this point. So if the new delta data could be sent in a DT_SECTOR_SOUND with some new flags, that should be the best solution.</blockquote>
Will do. I notice that there is already some flags that are OR'd in (DT_RESENT) so should I start delta type specific flags from a particular value?

skyjake

Do not add or modify the <tt>DT_</tt> enums. The correct place to add this new flag is to the flags field of the <tt>DT_SECTOR_SOUND</tt> message itself. The current flags are <tt>SNDDF_VOLUME</tt> and <tt>SNDDF_REPEAT</tt>, and they are read in <tt>Cl_ReadSoundDelta2</tt> on cl_sound.c line 105. Since the flags field is one bytes long, there is room for 6 new flags. In this case two are needed.

Adding flags here is backwards compatible because even if an old client reads the flags, it will still understand it's a sector sound and just use the default emitter.

When it comes to other new data, similar approaches should be taken. Also, since demos are just a recorded bunch of net deltas, we should try to do our best to keep things backwards compatible.

DaniJ

The reason I was considering new flags OR'd in with the delta type (not actually changing the delta type enums) was because the new flags only effect sector based sounds so it seemed a waste of bytes to use the flags field, where currently those flags effect all sounds.

skyjake

But the flags in the "flags" field of a DT_SOUND_DELTA can mean different things depending on whether it's a sector sound, mobj sound, polyobj sound, or whatever. Besides, it would go against the current design to store these flags (floor/ceiling origin) outside the sound delta message itself.

DaniJ

OK. Will do.

How do you suggest I add new data to eg a sector delta for the floor/ceiling surface colour values? Do you have an existing approach for adding new data to deltas (not new flags) that I should observe?