Many DirectX projects bring up errors when I try and compile them,
the errors seem to be of this form or similar:
"c:AdvAniBookCodeBookCodeCommonDirect3D.cpp(314) : error C2664: 'D3DXLoadSkinMeshFromXof' : cannot convert parameter 1 from 'IDirectXFileData *' to 'LPD3DXFILEDATA'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast"
i.e. for some reason the compiler recognises these pointers as being
of different types.
I'm using Windows XP, DirectX 9 and MS Visual Studio .NET 2003.
These errors did not occur when I was using MS Visual C++ v6.
I'd be grateful for any input on how to fix this.
WiffleCube.
Thanks. That type depreciated already? Ho hum. Another factor
that appeared during compilation is that MSVS .net throws an
error if you use aliases for classes, e.g.
typedef class2 class1;
If you passed an object of type class2 to a function expecting
an object of type class1 it throws an error. Overly strict
type-checking perhaps.
...well yes strict, but no, not overly strict.
Those two classes ARE different in every way that matters to the compiler. Only in a human programmer's mind could they be considered the same thing, and we all know that computers don't do well when they have to do what you mean, not what you said. :)
I struggle to think of a time in which aliasing in this way would be very good programming practice - could you elaborate on why you need to do it?
quote:
I struggle to think of a time in which aliasing in this way would be very good programming practice - could you elaborate on why you need to do it?
For example, in the above, where you're using DirectX library
functions, and it generates an error because you use LPD3DXFILEDATA
as a parameter instead of IDirectXFileData * and vica versa. MVC++
recognises these as being the same, whereas MSVS .NET throws an error.
Yes, there are two distinct objects in question:
typedef IDirectXFileData *LPDIRECTXFILEDATA; (deprecated)
typedef ID3DXFileData *LPD3DXFILEDATA;
D3DXLoadSkinMeshFromXof() takes a LPD3DXFILEDATA, which is a typedef of ID3DXFileData *, not IDirectXFileData *. I assume that the function took a LPDIRECTXFILEDATA before IDirectXFileData was deprecated.
I'm at a loss to explain why MSVC6 allows casting between these objects. It's not something you want to do (mainly for mcdrewski's reason). I'd say the best thing to do would be to declare the object as a LPD3DXFILEDATA in the first place and rewrite the functionality to conform with the new interface. I'm not sure how heavily it's used in your code but I imagine they're more or less functionally equivalent. Check the DX9 docs to see what's been replaced with what (The documenation should still reference both interfaces).
Oh man... M$ DX9/VS6 blues
Just ported a 3yr old Dx8/VC6 demo to DX9.0c/VC6,
which should have just been a recompile...
ok, so after rewriting chunks of code because of
deprecated APIs, I get this strange link error,
undefined symbol "security_cookie" in dxerr9.dll.
Many net postings about this, boil down to the fact that
M$ dont support VC6 with DX9 after october 2004, grrr.
Anyway, I just removed DXTrace() calls, which were only
reason for linking with DXerr9.dll, and it builds and
runs fine now on DX9.0c [the Feb 2005 SDK update]
This is all within the bounds of simple M$ silliness,
but I had similar type of problem when DX8/VS5 combo
was unworkable because the exe format had been upgraded.
Which meant I was forced to upgrade to VC6.
They just seem a bit arrogant... you can never get a straight
answer or simple DLL to fix the problem.
On the plus side I cut out a lot of code by using
DrawIndexedPrimitiveUP().
Whats the consensus of the current best target DX version?
DX8 well supported by most PC gamers?
Do you realise that vc6 is something like 8 years old, and is nowhere near as conformant as vc7.x? If you want to use vc6, then stay with the older SDKs.
And why would you think a major version upgrade is just a recompile...?
If you want to support the largest ammount of hardware, I think targeting DX7 is a good idea. DX9 should work on DX8 class hardware so I don't see any point in targeting just DX8.
Those pointers are of different types.
IDirectXFileData has been deprecated. Using ID3DXFileData instead should work.