Hello, sorry to bother you guys with this. I'm following along with the series and keep hitting a wall with VS when it gets updated.
I'm getting an error HRESULT 0x88780064 line line 376 of win32_handmade.cpp:376
I'm currently on day 106 but I think that the day is not at all relevant.
I was wondering if there is a particular package that I need to install or some backwards compatibility setting that I could use?
Thanks in advance, and ...
oh windows why why why?
:)
I have just tried installing VS 2019 on which the code was previously working, but it is still giving the same error.
Could a windows update create this kind of problem?
Did you try running Casey's code to see if the problem comes from your code ? Code from day 106 runs fine for me.
0x88780064 error code is DSERR_BADFORMAT which seems to indicates there is something your not setting up correctly. Here is the list of DirectSound error https://docs.microsoft.com/en-us/previous-versions/windows/desktop/ee416775(v=vs.85) and their values https://docs.microsoft.com/en-us/previous-versions/windows/desktop/ee416776(v=vs.85) and the doc for CreateSoundBuffer.
I remember a common error was to use fields from the WAVEFORMAT structure before they were initialized to compute other values because of how the doc presented the information.
Could you share your code to see if there is an obvious issue, or if it runs on my machine ?
Yes I always check against Casey's code, and am getting the same error with that.
When I compile and run day 106 I get an Exception on line 565 win32_handmade.cpp of Casey's code, the function call returns a null pointer.
Exception thrown: read access violation. GlobalSecondaryBuffer was nullptr.
I have suspected that there be a bug in the sound code somewhere for some time now as I would occasionally get a beep sound when using certain keyboard input movement combinations on both Casey's and my code, when the game is running.
Here is my edition of win32_handmade.cpp
I've also checked out and tested day 12, this generates the same exception.
What Windows are you running? I doubt it is Windows XP, but in those times this kind of DirectSound setup code might not work. Since Windows Vista DirectSound is software emulated, so it is more "flexible" in what formats it accepts - which is for what Casey wrote that code.
Are you sure calls to create primary buffer and setting its format succeeded? These two:
DirectSound->CreateSoundBuffer(&BufferDescription, &PrimaryBuffer, 0) PrimaryBuffer->SetFormat(&WaveFormat)
If they really did - double check format it actually uses. Add
char buffer[1024]; PrimaryBuffer->GetFormat((LPWAVEFORMATEX)buffer, sizeof(buffer), NULL); LPWAVEFORMATEX PrimaryFormat = (LPWAVEFORMATEX)buffer;
before place where you're creating GlobalSoundBuffer and then examine PrimaryFormat variable to see if it really has the same format as you expect.
Your code runs on my machine (at least the direct sound initialization). So doing what mmozeiko said is probably a good thing to do.
I don't know if it affects DirectSound (as it's emulated), but as we don't ask for exclusive mode audio, their might be limitation on the format. From the Core Audio documentation:
An application that uses WASAPI to manage shared-mode streams can rely on the audio engine to perform only limited format conversions. The audio engine can convert between a standard PCM sample size used by the application and the floating-point samples that the engine uses for its internal processing. However, the format for an application stream typically must have the same number of channels and the same sample rate as the stream format used by the device.
I understand that to mean that if some other currently running application uses more than 2 channels or a sample rate different than 48000hz than the stream creation could fail. I encountered that with WASAPI but I thought DirectSound would handle it so you don't have to care.
I'm running a licenced copy of windows 10. I have just updated my display drivers, possibly the sound driver too.
I believe the prior calls are successful, I've put the InvalidCodePath macro in the fail paths to be sure that they were not straight out failing.
Upon adding the code that you have recommended, the GetFormat function returns with the exact same type as WaveFormat, which was declared a little earlier.
wFormatTag 1 nChannels 2 nSamplesPerSec 48000 nAvyBytesPerSec 19200 nBlockAlign 4 wBitPerSample 16 bSize 0
Thanks for your help.
Well ... there is progress, but no cigar just yet though!
Upon reading your reply I've checked my audio setup, the code runs when I unplug my USB sound device.
Seems that there is no driver for it, the system hints that it does not require one; Something must have changed with a windows update as this was working before and there are no dirivers for the device that I am aware of.
I'm using a zedi10fx which has 4 channel, which could well be the cause of the problem, is it refusing the stream because it does not have 4 channels?