Horde3D

Using VS2008 or VS2010 on Windows 7, a Debug build hits this assert any time I try to load a DXT1 DDS:



The texture appears to successfully load, regardless of this assertion being hit. I'm using the C# bindings with the latest code in the SVN trunk, but I recall seeing this occur in prior releases (beta3, beta4) and in previous versions of windows (Vista).

Any ideas?

Mip-maps okay, if you've got them?

Renderer().calcTextureSize() look fine. (width/4) * (height/4) * 8 which for a 4x4 image would be 64 bits or 8 bytes as per the spec.

How are you loading the texture (utility library?), if the size passed into the load function was larger than the data it could definitely hit that assert, though it doesn't look like it would ever go exceed the bounds of a legit dds file, and would fail if your size passed in was too small.

If you're able to debug break after the assert it would be helpful to know the locals in the function.

Thanks for the reply, my artist believes the Mip maps are ok, it was exported from photoshop with the Nvidia DDS plugin.

Here are the locals when I break:



I use the following code to load it (and any other resource):



Attached is the dds, its a grey version of the one that comes with the samples, although I notice it is significantly smaller in size.

That would do it.

Appending the null is giving you an extra byte that the DDS loading isn't concerned about (since it's not dealing with text like an xml resource would be).

Agreed, I stepped through that section of code and in this case nullTerminate is false (as it is for all textures), so the byte does not get added. The bytes reported by windows for the dds match the size of the byte array I try to load (16592).

If I change the loadResource call to strip a byte off all dds:



The ambient shows up as yellow rather than the grey which is in the texture so I think my code is ok in this case

The strange thing is that even though it asserts, the visuals appear as expected.

An assertion isn't necessarily a problem just a notification of something unexpected occurring. "I expect this to be true, if not I want to know about it."

The assertion is triggered because the dds code assumes that the texture file buffer is also one byte larger (h3dutLoadResourcesFromDisk zero-terminates all files). This behavior is not obvious from the documentation which says just that XML files have to be zero-terminated. Maybe we should change that an recommend to zero-terminate all files.

Although it is somehow acceptable, I would prefer to get completely rid of this termination but unfortunately most XML parsers require it (although they could be modified to work with a size parameter instead).

Having to NULL-terminate all resources could cause some headaches.
For example, if you use another library for file loading (e.g. from an archive), then after that library gives me a buffer-of-bytes, I've got to memcpy the whole thing into a new buffer so I can append the 0-byte on the end (which horde will then mostly ignore anyway).

Thanks marciano, null terminating fixes the issue.

Good point. I would propose then that we make the null termination optional for xml resources only. If some xml data is not null-terminated, horde will handle that by creating a temporary buffer.

In some ways, that just masks the problem. Horde would then be performing a copy of possibly large amounts of data, for what is ultimately a book-keeping exercise. Perhaps the API could be expanded to accept a length parameter in place of a null terminator, and then operate directly on the data handed in?

_________________
Tristam MacDonald - [swiftcoding]

The API already has a size parameter for loading. The problem is the XML parser which does only work with null terminated data. Thinking about it again, I tend to make the termination completely transparent to the user and have Horde use a pre-allocated scratch buffer. Most xml files are quite small, so the performance overhead of the memcpy should be neglectable. Once we switch to a fast in-situ parser, it makes sense to have a local copy anyway since the parser will have to write to the memory.