Update Torque Engine SDK for VS .Net 2005

From Ben's Writing

Jump to: navigation, search

After considering some other options, if you must maintain the existing portability of the Torque Engine, then it would be better not to follow these directions and instead refer to the compiler flags that will make vc8 much less pedantic. For instance: /Zc:wchar_t- will solve the type conversion errors.

This article assumes you have downloaded and installed the Torque SDK 1.4 on your C: drive.

To start with in C:\Torque\SDK take the contents of vc7 and make a copy of it called vc8. This way you can always still compile it with vc7 (although I haven't made sure that the following changes won't break vc6/7 ... I'm sure they will ;)


The following changes will let you compile the thing.


typedef unsigned short UTF16;


typedef wchar_t	UTF16;

The problem here is that LPCWSTR -- used in CreateMutexW, and other platform dependent code -- is define in terms of WCHAR which is, in VC .Net 8 anyway, of type wchar_t, which is now a distinct from unsigned short.

The C++ Language Reference, under the heading of Fundamental Types, states that "[b]y default, wchar_t is a native type but you can use /Zc:wchar_t- to make wchar_t a typedef for unsigned short."


U16  ascii[3];


UTF16 ascii[3];

Got me on this one, it's the only time U16 is used when they probably meant UTF16. Technically it's valid, but considering they only did it once, it must have been a mistake.


int i;

Maybe they just forgot?! More likely VC6/7(.1) was nice enough to fill it in for them silently.





The problem here is that there is a core system header with the same name, that serves the same purpose, but because of the include directory order, this outdated file gets chosen first.


virtual BitmapLoadDlg(){ return 0; }
virtual ReloadBitmapAndUpdate(){ return 0; }


virtual int BitmapLoadDlg(){ return 0; }
virtual int ReloadBitmapAndUpdate(){ return 0; }

Again, here the older VC compilers were just a little more forgiving.


#pragma warning ( disable : 4430 )

That, or you could do the "right thing" and add the return types to every offending member function (namely int), as we did above. I just got lazy by this point and actually wanted to stop fixing the code and use it.

This leaving out the return type, again, is an example of a (not so) clever way of having the compiler write code for you that will later fail. I say this in jest, of course, as that's pretty much what my little disable-warnings-band-aid fix does :P


These aren't required, but they will cut back on the compiler noise.

Personal tools