16 replies to this topic

[Jan]

Hi

Got an annoying problem. I've been using Visual Studio 2002 and now switched to VS 2005. Everything compiles fine. However, when i try to link my program, it complains, that the following symbols are undefined:

nvDXTlibMT.lib(NormalMapGen.obj) : error LNK2019: Undefined extern Symbol ""public: void __thiscall std::_String_base::_Xran(void)const " (?_Xran@_String_base@std@@QBEXXZ)" in Funktion ""public: class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > & __thiscall std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::erase(unsigned int,unsigned int)" (?erase@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAEAAV12@II@Z)".

nvDXTlibMT.lib(NormalMapGen.obj) : error LNK2019: Undefined extern Symbol ""public: void __thiscall std::_String_base::_Xlen(void)const " (?_Xlen@_String_base@std@@QBEXXZ)" in Funktion ""protected: bool __thiscall std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::_Grow(unsigned int,bool)" (?_Grow@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@IAE_NI_N@Z)".


I use the nvDXTlib to load DDS files. Now, suddenly, after switching to VS 2005 i get these two error-messages. It seems, as if the programmers of the nvDXTlib used an implementation of the STL, that is not compatible to the one shipping with VS 2005.

Did anyone else encounter this problem? Any ideas how to work around it?

Note, that i downloaded the most recent nvDXTlib, but there seems to be no update, that fixes this problem.

Jan.

[Jare]

I don't think there's a publicily available fix for this. Bugging nVidia to release one would be the best approach.

[Kenneth Gorking]

Ha ha, good luck! I've tried to contact nVidia several times, but they never responded. Don't know what their problem is.

[Jan]

So, did you encounter the same issue?

[Jare]

Jan said:

So, did you encounter the same issue?

Same issue. In our case we have just kept the nvdxt-using code in VS2003 while the rest were moved to 2005, but that option is certainly not available to most.

If nobody has a good alternative to nvdxt, the best route is to just keep bugging nVidia.

[Jan]

Damn. :wallbash:

I mean, if they would release their source-code, everyone could just compile it himself. I was really happy to get free code, that would deal with DDS file loading, since i don't want to do that myself. But in the end all this is counter-productive.

I already send them an "error-report" (try sending them the error-message if you are not allowed to send them more than 900 characters!). I don't expect an answer, though.

Jan.

[Nils Pipenbrinck]

hm.. how about installing the old compiler, and link the lib into a dll? That ought to get rid of the runtime library problem.

I know, it's a dirty hack, but...

[Reedbeta]

The Cg toolkit includes some free code for loading DDS files. I don't think it's the same thing as nvDXTlib, but it's there, in examples/runtime_CgFX/nv_dds.h and nv_dds.cpp. Maybe that would serve until nVidia can fix this problem?

[Jare]

Hm.. one semi-related question: making a DXT decoder is an easy job, but I seem to recall that distributing a program that contains one actually requires a license from... S3? The D3DX runtime supposedly includes such a license, but does the nvDXT library?

Hope I'm not mudding the issue.

[Jan]

I tried the code shipping with the Cg SDK.

I think it's a piece of ****.

The code simply does not load DDS files. At least not files created with nVidias Photoshop plugin. I put some debug output into the loading code and the "load" function, that is supposed to read the DDS file fails at recognizing the DDS file. First it checks whether "DDS" is written in the file, which seems not to be the case (at least not where it tries to read it). Of course all subsequent checks (DXT FOURCC Code, ...) also fail.

I really need code, that reads a DDS file and is able to decode it, because i need the raw, uncompressed data. Exactly what the nvDXTlib does. I rewrote my whole texture-loading code, to at least be able to directly upload the data, because the Cg lib is not able to decode the loaded data. But then it simply didn't read the file at all, GRRRR !!!

Cunning as i am, i now SOLVED the problem :-D Yeah, i know, i am great. How i did it? I removed the DDS loading code and now load TGA files, again. Great, isn't it.

Maybe i will reinstall VS 2002 only because of this. Or i switch to D3D. So many options!

So, in the end i ask you: Did nVidia really do us a favor in releasing a library, that first allowed us to use the DDS format, but then dropping support for it, so that we are now hanging in the air and need to somehow do all this on our own? I think not.

I'm mighty disappointed.

Jan.

[Reedbeta]

That's very strange. It certainly reads the DDS files included in the Cg toolkit fine. And I looked at the DDS files produced by the Photoshop plugin in a hex editor, and they certainly have the 'DDS' at the beginning as you'd expect. So, I can't explain why you had such poor results with it.

If you wanted to develop your own DXT reading library, you could maybe start with the Cg stuff and then add decoding logic based on the information in this document, which describes the precise format of the compressed data (in the appendix).

[tri]

Hi all, what you need to do to get the lib to link with vs8 is define the missing functions in your own cpp file. Since nvdxtlib was compiled against an older VS, you'll need to use the older declarations. Your obj file will then contain the missing functions and the linker will be happy. Here's what I did:

//

// Crap to make the nvDXTLib link with the new VS8.

//

namespace std

{

	//

	// From old VS7 xstring.

	//

	class _CRTIMP2 _String_base

	{

	public:

		void _Xlen() const;

		void _Xran() const;

	};


	//

	// From new VS8 xstring.

	//

	//

	// class _CRTIMP2_PURE _String_base : public _Container_base

	// {

	// public:

	// 	_MRTIMP2_NPURE_NCEEPURE static void __CLRCALL_PURE_OR_CDECL _Xlen();

	// 	_MRTIMP2_NPURE_NCEEPURE static void __CLRCALL_PURE_OR_CDECL _Xran();

	// 	_MRTIMP2_NPURE_NCEEPURE static void __CLRCALL_PURE_OR_CDECL _Xinvarg();

	// };

	//


	//

	// From old VS7 string.cpp

	//

	_CRTIMP2 void _String_base::_Xlen() const

	{

		//

		//	_THROW(length_error, "string too long");

		//

		throw("string too long");

	}


	_CRTIMP2 void _String_base::_Xran(void) const

	{

		//

		//	_THROW(out_of_range, "invalid string position");

		//

		throw("invalid string position");

	}

}

[tri]

On a related note, I've been really happy with the (open source!) Squish encoder by Simon Brown (at least the later versions seem pretty solid):

http://www.sjbrown.co.uk/?code=squish

There is an API to encode whole images (even though the webpage doesn't mention it). It doesn't have all the features of the nVidia encoder and doesn't deal with resampling image, but it does a good job of encoding and is about as fast as the nVidia encoder.

As for decoding... well apart from it being trivial, I can see no good reason to need a software decoder. The whole point of s3tc is to let the HW do it. As for a dds loader... well the loader shouldn't decode the DXT blocks... just leave them in-tact. My own dds loader does happen to flip the image rows (cuz we're using OpenGL not DX) but that can be done without decoding the blocks... just massaging them a little.

tga's are great. Maybe consider having your pipeline use Squish or nvDXTLib to encode and generate the mipmap levels automatically.

[Jan]

Hi

Great, thanks!

Of course S3TC is about decoding that stuff in hardware. But sometimes you need a software-decoder, because you want to make a tool that processes image data. DDS is mainly about getting the textures into the hardware efficiently, but sometimes you need to work on the raw image-data.

Jan.

[tri]

Hi Jan,

Hope the code worked for you. I suppose the discussion of a software dxt decoder is a bit of a philosophical one... but I think reasonably important. I suppose I agree that there are rare cases where a decoder could be justified... like for a dds viewer where you don't want the image to look like what the HW would give you (ex: older nVidia cards use 16bit interpolation... giving that ugly banding). Another reasonable use might be validating or computing error metrics for various compression schemes (HW or SW).

However, since s3tc is lossy... and badly lossy at that (much worse than, say, a jpg, at the same file-size), I think it's a mistake to process the dxt blocks except for simple lossless manipulations (row flips, mirror images, etc). Personally I don't even like doing edits to jpg's, and the generation loss with a jpg is much lower than with a s3tc image.

Processing dds files in general is reasonable though... there are many other supported pixel formats... many of which are lossless in an editable way.

Anyways, these are clearly just my opinions... obviously Photoshop with the NV dxt plugin allows editing dds's with dxt data in them... so I suppose there are smart people out there that disagree with me ;) ah well.

[seboslaw]

Hi there,

has anyone gotten tri's snippet code from above to run? If I put it in my cpp file, I get class redifinition errors (right where _String_base gets defined).
Can anyone help?

Cheers,

Sebastian

[tri]

This was worked out off-forum using e-mail. Soln was:

Create a new module and define LEAN_AND_MEAN before including windows.h. Then use the code above.