Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Determine usability of digiparm.bin #56

Open
dertseha opened this issue May 23, 2017 · 3 comments
Open

Determine usability of digiparm.bin #56

dertseha opened this issue May 23, 2017 · 3 comments

Comments

@dertseha
Copy link
Member

User "zombe" on the TTLG forums had a hunch about digiparm.bin being used for sound attenuation.

Determine whether this file has any effect, and whether it needs documentation.

@dertseha
Copy link
Member Author

Following up on this, I made some investigation, including the files from the two demos and the two releases (HD and CD each).

Results so far:

  • This file appears to be a raw dump of three byte arrays, each array equally sized.
  • The size of the arrays correlates with the amount of sound effects in digifx.res
  • The first array does indeed govern sound attenuation. The byte has a range of 0x00..0x7F with larger values being handled as if they were 0x7F.
  • The other two arrays seem to have no effect. (Details below)

An attenuation of 0x00 completely silences the sound, 0x7F plays it unmodified. Attenuation appears to be linear.

The two demos, as well as the HD-release, have 111 sounds, and the CD-release has 115 sounds in digifx.res . The digiparam.bin file of the demos and the HD-release has a size of 333 bytes (3x111), whereas the file of the CD-release has a size of 342 bytes (3x114).

This shows a mismatch in the CD-release - the bin file expects 114 sounds, the res file contains 115 sounds. The last sound is just silence, though it can be used like any other. I tested this by importing a proper sound and setting it as a critter sound. This test the furthermore required the modification of the actual last byte of the first array to a higher value.

By default, this first byte of the second array is set to 0x01, with other values like 0x02, 0x04, and 0x09 found in the second array. The third array has commonly the value 0x0A, with some exceptions of 0x02, 0x08and0x0B```. (Note: these example values are from the CD-release; the other files contain slightly different values).

I now suspect that the second and third arrays are not used in the game. This is backed up by tests changing the values of test-sounds, without effect. I tested this with both the CD-release and the HD-release.
Effects I thought about: Occlusion properties (any changes if sound is behind a wall), Size properties (does attenuation by distance behave differently).

@dertseha
Copy link
Member Author

Leaving this to sit for a while, then a block note to the sound effects could be added about this file. After all, modifying the sounds requires also a modification of this file for proper results.

What is also missing is a test whether the amount of sounds is hardcoded, or dependent on the amount in digifx.res. I couldn't test this so far, since the tool chunkie still doesn't support adding new chunks yet ;)

@winterheart
Copy link
Contributor

According to DIGIFX.C, there 3 arrays:

  • volumes[114] - volume of sound
  • flags[114] - ?
  • priorities[114] - priority of sound (?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants