Silent fall

[Paul Stevens]

If you had a function like 'PlaySound( sound ID, volume)' that would simply play any number of sounds at the same time, would that be enough?

That is essentially what we have now. Except that there is no
'SoundID'. What we have is an in-memory wave file..... a
collection of 8-bit PCM samples that need to be played at 6000
samples per second. We also need to know when to release
that memory (or have your PlaySound function release the
memory when the sound is finished).

[cowsmanaut]

Right, there'd be 'SoundStartup' 'SoundPlay' 'SoundStop' and 'SoundShutdown'. These would take care of loading the sounds, playing, etc. everything. The calling code just needs to say what to play when. I figure this should be a platform independant enough of an API, and you just need a multisound capable implementation of it for at least win32. Other implementations can use their current single sound libraries (but following the same API given here so that they can be fully implemented later).

For the Win32 port, all of the DirectX stuff will be in this code, the main engine code will never see DirectX

Just figure out all the ways you need to play sounds, like being able to stop individual sounds after they've started, being able to play them each at different volumes, perhaps their physical location for 3D sound (ignored if it's not supported on that platform of course), etc.

[Paul Stevens]

Just figure out all the ways you need to play sounds

I need a single function with exactly one parameter.

bool PlaySound(WAVEFILEHEADER *pWave);

pWave has been allocated off the heap and PlaySound should
free() it when it is no longer needed. It should be played at
full volume because we have already adjusted the volume for
distance-from-party and for the Volume menu.

The return value should be true if the function succeeded.
If the return value is false then I will disable subsequent calls
to PlaySound(), I will play the sound myself, and I will free(pWave).
The return value will be false, for example, if DirectSound cannot
be loaded or the platform does not support whatever is needed
to accomplish the task.

PlaySound should do any necessary SoundStartup transparently.
Probably the first call to PlaySound can initialize anything that
needs initializing. Or it can use constructors to initialize. There is
no need for SoundShutdown() because it can use destructors for
that purpose.

Using this model, we can dispense with any user interaction and
assume that whatever PlaySound does is equal or better than
what CSBwin can do for itself.

[cowsmanaut]

That will really limit what the library can do, since it has to convert from a WAV format into its internal format on each function call. Unless that's what DM really wants to generate it'd be much nicer to abstract more of the process. It also hurts performance a lot this way since a sound buffer can't be loaded into the sound card.

The function would always succeed and play the sound through whatever mechanism necessary (like falling back to WinMM if necessary). So that way there is no sound playback routine in the core code.

This code should be compiled in conditionally for the windows version, so it'd be a part of the main app. The code wouldn't be very big, just a single .cpp and .h file.

[Paul Stevens]

convert from a WAV format into its internal format

A .WAV file is an ordinary PCM-encoded sound. What encoding
does your proposed library function use? All the other platforms
are quite happy with a PCM-encoded sound file.

What about WindowsCE and the PocketPC?

Unless that's what DM really wants to generate

Not that it want to. That is what is in the graphics file. There
is little choice about where to start.

hurts performance a lot this way

How many milliseconds for a 0.5 second sound do you figure
will be required?

[cowsmanaut]

The format is internal, the sound driver takes in the WAV data and returns you a handle to the object that you can play it with. Then you can just play through the handles. No more loading from the .dat or doing any conversion.

WindowsCE and PocketPC can do what they do know, the API doesn't mandate change. The idea is to have the API allow the implementation to do what it wants, rather than force it to import the WAV each time.

How many milliseconds for a 0.5 second sound do you figure
will be required?

Why load the graphics into memory when you could load them from disk each time they're needed? It's a small number, but why make it inefficient and harder for the API to be implemented cleanly? Remember.. that .5 is added latency to your sounds!

Also.. as I said. If it's an issue about code. I can most likley get some..

[Paul Stevens]

Why load the graphics into memory when you could load them from disk each time they're needed

I don't thinkj you understand what I have done here. I took the
machine-language for the Atari CSB and translated it to
assembly language for the 68000 and then translated the
assembly language to C/C++. It all worked great. It works
just like the Atari did.

I had to make some changes here and there. For example:
The Atari code sent the sound samples off to the sound chip
one at a time by getting an interrupt every few microseconds.
That was not reasonable for Windows.

I gathered all the sound samples together and sent them to
the operating system to be played on the sound card. I would
happily send those sound samples to your function to be played
however you want to play them. But I don't know how the
Atari code decides what to play. I don't know where the samples
come from. I don't know how they got there. I could find out.
But as I said before, I am not interested in rewriting the Atari
code for the sake of playing two sounds at once. It simply is not
worth the effort.

All of this arose before in the context of the video display. This
is just like that. In that case I moved the pixels from the Atari
screen onto the windows screen. I don't know how the pixels
got onto the Atari screen and I was not about to try and figure it
out so that it could be changed. Same here with the sound. The
Atari code produced the PCM samples and I intercepted them and
played them. They were created in memory and so that is
where I retrieved them. God only knows how they got there.


The in-memory PCM samples ****ARE**** the form of the
sound at the interface between the original Atari code and whatever
code we use to turn them into audible sound. That is how it is.
It is our job to figure out how to use them in that format. I have
figured it out for Windows95, Windows98, Windows2000, WindowsXP.
Tomas has figured it out for macintosh. Erik has figured it out for
Linux. I have figured it out for WindowsCE. Now it is your turn
to figure it out for whatever scheme you choose. After I send
you the samples, you are welcome to write them to disk or
whatever you like. You might, for example, want to keep a cache
of sounds in an internal format. You are welcome to do that. A
quick hash-code scheme would suffice to give them short identifiers
if that is what is needed. There can't be more than a few thousand
different sounds. You can search a ten-thousand-entry table
in a couple hundred microseconds on even the slowest machine.
That is completely negligible overhead. I know how to do these
things but it ain't worth it to me. I have 42 cards in my pocket, of
which perhaps half are going to get done. I cannot do everything.

[cowsmanaut]

this is where I point out I've been parroting information back and forth as it's been explained to me. So this is me again.. with my own little side suggestion.. Which may likley get me smacked upside the head from both of you but...

What if we pulled the sounds from a selection of ripped wavs? Part of the previous issues with sound were that all of the sounds were not available to us. Some things like the horn of fear, and one of the walking sounds for a monster.. some others.

Anyway, is that a possible solution? Beyond all this hunting through a captured file and trying to determine beginning and end of the individual sounds. I know most of them have already been ripped. In fact I think Gambit has a selection of them he's played with for RTC as well.. This also opens the possibility for people to re-record or resample the sounds to suit their own dungeons.

Is this shooting too far?

also.. I don't expect you to do everything Paul.. you've been very generous as it is. Just thought I should mention that.

moo

[Paul Stevens]

What if we pulled the sounds from a selection of ripped wavs

That will certainly work. But.........I am not going to make
my 'official' releases with a bunch of .WAV files. I tried very hard
to keep the file set to a minimum. Even the config.txt
file is not absolutely necessary.

Moreover, in order to use any external files, especially monster
movement sounds or other sounds not already in the game
as I built it, will require that someone dig through the code and
figure out where and when such sounds should be played.
Then they have to check to see if the sounds are available and
figure out how to play them reasonably.

It breaks with the basic philosophy of the game's structure. It
has an executable, a graphics file, and a dungeon file. Now Zyx
has released ConfluxII and we certainly broke the mold with
all his portrait files. That was done because it turned out to be
so easy to locate the proper place in the code to do the substitution.
And it does not affect the standard DM/CSB games that do not
contain references to external portraits. Unfortuately, all the
standard games have 'WarCry' and 'Monster Movement'. If the
sounds for these are in the standard 'Graphics.dat' and someone
can fix the code to use them then that is great and I will accept the
changes with pleasure. But I ain't gonna do it unless someone
can describe the needed changes in some detail and can convince
me that it is easy and will work.

There is also the long-standing offer to help anyone who wants
to take my code and adapt it for their own use. We did this once
upon a time when someone wanted to make a DM with various
features that I did not approve. He released his version and it
worked well. I think was DjArcas who added some cheats.


Edit.........I would also be open to encoding these additional
sounds ( in the 4-bit compressed format ) right into the
executable. If they are not in the graphics.dat. But still someone
needs to fix the code and supply the sounds.

[Gambit37]

I could supply the 4-bit sounds; in fact anyone can rip them out of an Amiga graphics.dat using Rain's dmextract or similar tool.

I haven't the first clue about coding though -- I'll have to leave that one to someone else. Quite happy with a bit of Javascript or PHP here and there -- but pure coding? You can count me out!

As for playing external sounds -- from a dungeon designer's point of view, that's even better. But I can see how this would be tricky, and I too rather like the self contained nature of dungeons as they stand: one dungeon.dat and one graphics.dat.

Personally, I would love CSBWin to support the extra 'missing' sounds from the PC and Amiga version. I really miss hearing monsters trudging around after me.

Hey, here's an idea Paul. Perhaps you could reverse engineer the Amiga version as well??

[Zyx]

The sounds are at the end of the graphics.dat.
It should require very extra knowledge to add some more into the graphics.dat.
The first part of this file states how many sounds -and graphics- there are, how long they are and where they start. So this index should be updated too.

CSBwin would automaticly load them, using this index at the first part of the graphics.dat. So CSBwin needs no change, I guess.

Maybe we would need an updated version of CSBedit, maybe it already can do that if we edit the dmout.gil. I'll have a try if nobody else does.

With CSbedit we could edit which sound makes a monster when attacking. I don't know where are the other actions that could be associated to a sound (like monsters moving noisily: maybe it's not coded in CSBwin?)

[Gambit37]

Yes, the hard part is adding the code to play extra sounds -- I doubt this is in CSBWin because the code presumably was only added to the PC and Amiga versions.

I've been slowly identifying the sound numbers in CSBedit. There are 256 and I've got as far as 200. Many of the sounds are repeated, and some have different volumes. Some sound IDs crash the game. Others produce static. Perhaps some of these could have new sounds assigned to them?

[Paul Stevens]

Your work is welcome. If you can change the
graphics.dat to contain and use new sounds then
that is great. One thing I object to is changing
CSBwin in a way that make it difficult to use the
original graphics files and dungeon files. You can
use custom graphics and I will help as best I can
but I will continue to release a CSBwin that uses the
original files. The other thing I object to is making
CSBwin use those massive libraries for its simple
graphics and sound requirements.

As I said, the use of the portrait files did not change
the way the original graphics and dungeon files worked.
And it was easy to do. Those are my primary criteria
for making such changes to CSBwin. I have made massive
changes to CSBwin but I am always very sensitive to
any reports that the original DM and CSB files do not
work in the way they worked (or, at least, were obviously
intended to work.....whatever that means ) on the Atari.
Bug fixes and the re-introduction of pieces that are missing
because of hardware limitations are fair game. I place the
monster sounds and WarCry in that last category but it has to
be done in a way that uses the original files.

[cowsmanaut]

Ok, have my friend working on the code for the mixing based on what you've said. He agrees your way is best. .. so that takes care of the (smaller?) issue..

Beyond that there is still the issue of sounds that were missing. As I've said before the sounds were stored in raw format within the .dat file for the amiga and I was able to hear and extract them on the amiga using basic sound editing software.

So, my question here is if I've ripped them and kept them all seperate 8bit pcm files.. would that be acceptable? They should remain fairly small and could be provided as a seperate download even, if it's still more of an addition than you would care for.

As I said this offers the chance to make new sounds..

However, if ZYX can get them into the Graphics.dat file then that's cool too. Just wondering what's the most benefitial, or rewarding?

I know you said there is a lot of code to go through to find within the code where they must be placed.. but do you have an ideas as to where it might be? I mean as end user I can easily say.. ok this sound plays when I use the blow command on the horn of fear... or this sound plays when I hit the war cry button. However, in dissasembled code that is just a buch of letters and numbers.. well, makes little sense to me.. or most people.

Anyway.. I dunno what the solution is.. but I place my self available for some kind of menial task that doesn't require programming knowledge

moo

[Zyx]

I added the sound accordingly to my knowledge of the graphics.dat structure.

Unfortunately CSBedit cannot edit it anymore, and CSBwin crashes with this error:
"You have encountered code at 0x0085f8 that I thought was unused"

[Paul Stevens]

Cowsmanaut:

The WarCry is straight-forward. There is
a place where an 'Attack' takes place and a spot in the
code where 'WarCry' is accomplished. You simply need to
queue the sound at that spot.

The monster movement is much more difficult. You certainly
cannot queue the sound every time any monster moves.
There needs to be some test to see if the party is near, if
walls intervene, whether a door is open a false wall open,
etc. before issueing the sound and determining its volume.

If the sounds are not in the Atari CSB or DM graphics then
if you want these sounds to be in the standard release of
DM and CSB then we need to put them into the executable itself.
For that purpose it is best to have the original 4-bit, compressed
format simply to save space.

Zyx:
0x85f8 is in one of the video graphics handlers. An illegal
video format was encountered. So adding the sound made
one of the pictures get confused.

[Zyx]

I managed to add 8 sounds to a graphics.dat. CSBedit can still edit the file and CSBwin doesn't crash. But I don't know which index they would have. Gambit, can you send me your studies on the indexes?

[Gambit37]

I don't know how useful it would be -- it's just a list that says 1=Thud, 2=Door, etc.... It's currently on paper so give me a while to type it. I didn't do the whole let, about 50 to go.

Any good to you?

[Zyx]

Yes, it would be useful, at least for avoiding the crashing indexes and the already existing sounds!
Maybe I will manage to deduce which would be the new indexes using your list?

[Gambit37]

Here you go:

Code: Select all

The following IDs crash the game:

14, 18, 19, 25, 29, 39, 49, 52, 65, 66, 69, 78, 91, 95, 102, 103, 104, 117, 121, 123, 127, 130, 136, 143, 147, 149, 151, 153, 162, 183, 193, 199, 205, 214, 219, 221, 226, 231, 233, 247, 248, 255

These IDs play static (normally just a click, but some are a bit longer and at different pitches):

26, 37, 40, 42, 44, 55, 73, 84, 90, 92, 108, 118, 122, 141, 157, 159, 169, 171, 174, 188, 195, 207, 220, 235, 245, 252, 253

These IDs play LONG static/distorted sound:

237

List of sounds:

Dragon/Rat: 1, 56, 59, 67, 87, 93, 163, 166
Ghost/Mummy: 2, 116, 168, 184, 191, 244
Screamer/Oitu: 3, 54, 250
Scorpion: 4, 41, 46, 94, 210, 225, 236
Worm: 5, 76, 107
Giggler: 6, 128, 249

Thud: 7, 12, 33, 38, 113, 137, 206
Dink: 9, 22, 34, 36, 48, 60, 72, 74, 85, 86, 88, 98, 100, 112, 124, 126, 138, 140, 150, 152, 164, 170, 176, 178, 190, 192, 201, 202, 204, 215, 216, 228, 230, 242, 254
Click: 10, 35, 108, 111, 114, 115, 134, 212, 238
Door Clank: 30, 61, 80, 82, 106, 160, 186, 194, 196, 218, 246
Teleport: 24, 179, 180
Swipe: 8, 63, 110, 182, 224
Drink/Eat: 15, 28, 120, 217
Party runs into wall: 146, 154
Fireball (soft): 16, 47, 145, 203, 232
Fireball (loud): 43, 64, 68, 139, 142, 158, 173, 175, 177
Party Hurt: 70, 71, 77, 101, 119, 132, 167, 172, 208, 223, 243
Party Die: 62, 165, 189, 241

I believe there are four Party Hurt sounds and this list includes at least two different ones, but I haven't identified which is which yet.

I have yet to find the Magic Fuse sound, I assume it's between 200-255.

[Zyx]

Thank you!

[Gambit37]

You're welcome! Oh, I forgot to mention -- if a number's not listed, then it does nothing.

[cowsmanaut]

Ok, so the "Programmer Dude" I asked to write the code wants to know the format it will be passed to his code as, also what rate and how many bits.

[Paul Stevens]

It is in the standard .WAV file format. It has the header information
and such that is needed to determine the sample rate, sample
size, number of channels, etc.

If you look in Sound.cpp and at function SoundDecode()
you will see the header and the data being built. It is all
quite straight-forward. Your function can extract the
necessary information from that header.

[Gambit37]

I updated the list with all the valid sound IDs from 0 to 255. The magic Fuse sound appears NOWHERE in this list, so I really don't know what use this list actually has as it's clearly not the full list of available sounds.

Maybe one of the static sounds is the Magic sound? Who knows. Make of it what you will.

[cowsmanaut]

hmm.. I thought src.rar was the source for CSBwin.. but it's password protected. Which one contains the full src for CSBwin.. or at least the one with the file you requested he look at?

moo


edit.. NVM. I guess it's in CSBsrc96.rar... duh ok I'm a little slow.

[cowsmanaut]

http://dmweb.free.fr/Stuff/files/Win ... dMixer.zip

there it is. He says it worked in his "test harness" and then said something about "But he's going to have to hash them if he wants it to reuse buffers."

so yeah.. check it out.

moo

[Paul Stevens]

Thanks. I got it.

[Paul Stevens]

It all came through intact but does not compile.

The first error is an undefined symbol: 'IDirectSound8'.

[cowsmanaut]

"Tell Paul I'll make it use the base DirectSound if he can't get the latest headers for it."

nuff said

moo