A few vista related DX questions
Author
I'm trying to get our software up and running on Vista, I'm just about there but have a few points.
1) Am I right in thinking DX9 on Vista is different to the DX9 on XP? I did hear it was a different version 'EX' or somtehing? I'm over my DX problems but I just want to clarify it.
2) Direct sound. Well, this has been removed and all DSound is done in CPU apparently. I'm having problems trying to create anything more than 2 channels and more than 16 bit. Does Vista detect I only have headphones plugged in or something? Why can't I get a 32 bit buffer?
Any other pitfalls people have run into on Vista would be good to hear about too.
Cheers
DirectX9 is the same on Windows XP and Vista.
A D3D9 software made on XP works without any kind of modification on Windows Vista.
For users who have got vista on their pc, there is a D3D9 Extension (called D3D9Ex) that adds some new things (but nothing of vitaly).
In documentation you can find new features.
A D3D9 software made on XP works without any kind of modification on Windows Vista.
For users who have got vista on their pc, there is a D3D9 Extension (called D3D9Ex) that adds some new things (but nothing of vitaly).
In documentation you can find new features.
D3D9 is actually different on Vista, at least behind the scenes. This is due to the revamped display driver model. However if you use straight-up D3D9 code and create an IDirect3DDevice9 interface, everything will behave exactly as it did in XP. For example lost devices don't occur in Vista, however they will be emulated for you so that your code can run exactly the same.
If you want you can create the IDirect3D9Ex and IDirect3DDevice9Ex interfaces, which are available only on Vista. These have some extra functionality for resource sharing between different apps, and other things of that nature. If you decide not to mess with it, you won't be missing much (IMO).
If you want you can create the IDirect3D9Ex and IDirect3DDevice9Ex interfaces, which are available only on Vista. These have some extra functionality for resource sharing between different apps, and other things of that nature. If you decide not to mess with it, you won't be missing much (IMO).
Author
I've discovered the D3D dlls from older distributions don't work on Vista. We actually package up two versions of D3D.dll with our app (one from oct 2005 and one from Feb 2007) as they fix and break various compatibilities in Win2K. However, when I ran the app up on Vista neither of these versions worked and after I'd deleted them it ran with the Vista dlls in system32 and was ok.
This is a bit of a specialised problem though as most apps use the D3D dlls already installed on the system and don't take their own to the party.
The plan is a move to DX10, but this is just an interim step for Vista. Still having problems with sound though....
This is a bit of a specialised problem though as most apps use the D3D dlls already installed on the system and don't take their own to the party.
The plan is a move to DX10, but this is just an interim step for Vista. Still having problems with sound though....
Quote:Original post by theZapperDistributing the D3D DLLs is against the DirectX EULA, since it can cause all sorts of security issues (Custom installed DLLs can't be patched via Windows Update for instamce). I'd be inclined to look at what's causing the compatibility issues, it's likely something wrong with your code.
I've discovered the D3D dlls from older distributions don't work on Vista. We actually package up two versions of D3D.dll with our app (one from oct 2005 and one from Feb 2007) as they fix and break various compatibilities in Win2K. However, when I ran the app up on Vista neither of these versions worked and after I'd deleted them it ran with the Vista dlls in system32 and was ok.
This is a bit of a specialised problem though as most apps use the D3D dlls already installed on the system and don't take their own to the party.
The plan is a move to DX10, but this is just an interim step for Vista. Still having problems with sound though....
Author
Quote:Original post by Evil SteveDistributing the D3D DLLs is against the DirectX EULA, since it can cause all sorts of security issues (Custom installed DLLs can't be patched via Windows Update for instamce).You know what? that's a very good point and I doubt many people here know about it.
The guy that originally did this has now left, and most of the stuff he did was his work only and a bit of a black box to everyone else. I'd better check that I know exactly what it's doing. Apparently he put something in that worked on XP but not on 2K, so there is a different dll for Win2K that loads an older D3D dll.
Quote:Original post by theZapperAll DirectX code should "just work" on 2k if it works on XP. The only exceptions would be window related things (E.g. You can't get WM_INPUT on 2k, but you can on XP). If you've got problems with 2k <-> XP compatibility, then there's a good chance you'll have XP <-> Vista problems.Quote:Original post by Evil SteveDistributing the D3D DLLs is against the DirectX EULA, since it can cause all sorts of security issues (Custom installed DLLs can't be patched via Windows Update for instamce).You know what? that's a very good point and I doubt many people here know about it.
The guy that originally did this has now left, and most of the stuff he did was his work only and a bit of a black box to everyone else. I'd better check that I know exactly what it's doing. Apparently he put something in that worked on XP but not on 2K, so there is a different dll for Win2K that loads an older D3D dll.
One other thing I can think of is doing things like reading from Lock()ed pointers after the Unlock() call and suchlike - that's bad on any OS, but might "Just Work" on some.
If you can find out what doesn't work on 2k, we can help you resolve that, which should probably fix any Vista problems.
Author
Quote:Original post by Evil Steve
All DirectX code should "just work" on 2k if it works on XP. The only exceptions would be window related things (E.g. You can't get WM_INPUT on 2k, but you can on XP).
I believe it was somthing to do with Cleartype on 2k, which has nothing to do with DX so I'm not sure why the 'fix' was done.
On a closer inspection it appears we are using the d3dx9_27 and _32 dlls. I've had a quick search and it seems that D3DX went a bit tits up in Feb 05, missing out the D3DX dlls. Maybe this is a bodge to get around that. I think I need to find out the exact reasons why this has been done because it seems like a crap solution to me.
Now then, DirectSound issues anyone? :-)
Author
Yeah, sure. Here is the original code, with the comments on the changes I made to get it working.
I've removed all the extra crap in between that doesn't apply, I think this is all that's needed. This works with my fixes but it's really shitty, plus it plays back at half speed which I guess is just because it's been sampled at 32bits but playing at 16. I have some output from the debug dll, but I'll have to dig that out for tomorrow.
Cheers for looking anyway people.
// description of the WAV format that we'll use for the secondary buffer memset( (void*)&m_WaveFormat, 0, sizeof(m_WaveFormat)); m_WaveFormat.Format.wFormatTag = WAVE_FORMAT_EXTENSIBLE; m_WaveFormat.Format.nChannels = m_IsForcingMixToStereo ? 2 : kNumChannels; // <------- kNumChannels is 8, which doesn't work, 2 does. m_WaveFormat.Format.nSamplesPerSec = 48000 ; m_WaveFormat.Format.wBitsPerSample = 32; // <----- BREAKS! 16 works m_WaveFormat.Format.nBlockAlign = (unsigned short)((m_WaveFormat.Format.nChannels * m_WaveFormat.Format.wBitsPerSample) / 8); m_WaveFormat.Format.nAvgBytesPerSec = m_WaveFormat.Format.nSamplesPerSec * m_WaveFormat.Format.nBlockAlign; m_WaveFormat.Format.cbSize = 22; // sizeof(WAVEFORMATEXTENSIBLE) - sizeof(WAVEFORMATEX);// I also set this to 16 m_WaveFormat.Samples.wValidBitsPerSample = 24; // so direct sound will assume that the l.s. byte is not required. (was m_WaveFormat.Format.wBitsPerSample) m_WaveFormat.dwChannelMask = channelMask;//SPEAKER_FRONT_LEFT | SPEAKER_FRONT_RIGHT | SPEAKER_BACK_LEFT | SPEAKER_BACK_RIGHT; m_WaveFormat.SubFormat = KSDATAFORMAT_SUBTYPE_PCM; memset(&m_BufferDesc, 0, sizeof(m_BufferDesc)); m_BufferDesc.dwSize = sizeof(DSBUFFERDESC);// describe the secondary buffer m_BufferDesc.dwFlags = DSBCAPS_GLOBALFOCUS | DSBCAPS_CTRLVOLUME | DSBCAPS_CTRLPOSITIONNOTIFY | DSBCAPS_GETCURRENTPOSITION2; m_BufferDesc.lpwfxFormat = (WAVEFORMATEX*)&m_WaveFormat; m_BufferDesc.dwBufferBytes = bytesPerSample() * m_BufferSizeInSamples; hr = m_DS8->CreateSoundBuffer(&m_BufferDesc, &m_Buffer, NULL);I've removed all the extra crap in between that doesn't apply, I think this is all that's needed. This works with my fixes but it's really shitty, plus it plays back at half speed which I guess is just because it's been sampled at 32bits but playing at 16. I have some output from the debug dll, but I'll have to dig that out for tomorrow.
Cheers for looking anyway people.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement