Compilation problems

Submitted by WiffleCube on
Forum
Programmers

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.

Submitted by TheBigJ on Fri, 20/05/05 - 4:10 AMPermalink

Those pointers are of different types.

IDirectXFileData has been deprecated. Using ID3DXFileData instead should work.

Submitted by WiffleCube on Sat, 21/05/05 - 4:55 AMPermalink

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.

Submitted by mcdrewski on Sat, 21/05/05 - 5:59 PMPermalink

...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?

Submitted by WiffleCube on Sun, 22/05/05 - 12:18 PMPermalink

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.

Submitted by redwyre on Sun, 22/05/05 - 1:18 PMPermalink

I don't think they are the same.. based on the naming standard (add "LP" to the begining and make it capitals) "LPD3DXFILEDATA" would be "ID3DXFileData*", not "IDirectXFileData*". But I'm guessing.

Submitted by mcdrewski on Sun, 22/05/05 - 8:42 PMPermalink

Agreed, but whether they're functionally identical or not, I bet you don't recall that for a few hours when you come back to your code in a year's time (or, god forbid, someone ELSE comes to it then).

Using one or the other would be my suggestion.

Submitted by TheBigJ on Mon, 23/05/05 - 10:28 AMPermalink

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).

Submitted by davedx on Tue, 07/06/05 - 11:25 PMPermalink

Maybe he had a different version of DX9 setup in VS6 and .NET? I seem to remember that got deprecated somewhere around 9.0b-9.0c... and I think b and c installed to different places on my box at the default setting. (So now I have a c:dx90sdk and a c:program filesdx90sdk, meh).

Submitted by justgord on Fri, 24/06/05 - 9:18 AMPermalink

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?

Submitted by redwyre on Sat, 25/06/05 - 1:00 AMPermalink

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.

Submitted by Daemin on Sat, 25/06/05 - 11:43 PMPermalink

Yeah, Microsoft abandoned support for Visual Studio 6 with the DirectX 9 SDK. That means get a newer version if you want to do DirectX 9 stuff, or use an older SDK like redwyre suggested.

Forum
Programmers

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.

Submitted by TheBigJ on Fri, 20/05/05 - 4:10 AMPermalink

Those pointers are of different types.

IDirectXFileData has been deprecated. Using ID3DXFileData instead should work.

Submitted by WiffleCube on Sat, 21/05/05 - 4:55 AMPermalink

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.

Submitted by mcdrewski on Sat, 21/05/05 - 5:59 PMPermalink

...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?

Submitted by WiffleCube on Sun, 22/05/05 - 12:18 PMPermalink

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.

Submitted by redwyre on Sun, 22/05/05 - 1:18 PMPermalink

I don't think they are the same.. based on the naming standard (add "LP" to the begining and make it capitals) "LPD3DXFILEDATA" would be "ID3DXFileData*", not "IDirectXFileData*". But I'm guessing.

Submitted by mcdrewski on Sun, 22/05/05 - 8:42 PMPermalink

Agreed, but whether they're functionally identical or not, I bet you don't recall that for a few hours when you come back to your code in a year's time (or, god forbid, someone ELSE comes to it then).

Using one or the other would be my suggestion.

Submitted by TheBigJ on Mon, 23/05/05 - 10:28 AMPermalink

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).

Submitted by davedx on Tue, 07/06/05 - 11:25 PMPermalink

Maybe he had a different version of DX9 setup in VS6 and .NET? I seem to remember that got deprecated somewhere around 9.0b-9.0c... and I think b and c installed to different places on my box at the default setting. (So now I have a c:dx90sdk and a c:program filesdx90sdk, meh).

Submitted by justgord on Fri, 24/06/05 - 9:18 AMPermalink

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?

Submitted by redwyre on Sat, 25/06/05 - 1:00 AMPermalink

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.

Submitted by Daemin on Sat, 25/06/05 - 11:43 PMPermalink

Yeah, Microsoft abandoned support for Visual Studio 6 with the DirectX 9 SDK. That means get a newer version if you want to do DirectX 9 stuff, or use an older SDK like redwyre suggested.