Horde3D
http://horde3d.org/forums/

Assert in egTexture.cpp loading DDS
http://horde3d.org/forums/viewtopic.php?f=2&t=1091		 Page 1 of 1
Author:  craigomatic [ 01.02.2010, 23:27 ]
Post subject:  Assert in egTexture.cpp loading DDS
Using VS2008 or VS2010 on Windows 7, a Debug build hits this assert any time I try to load a DXT1 DDS:

Code:
ASSERT( pixels == (unsigned char *)data + (size - 1) );


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?
Author:  AcidFaucet [ 02.02.2010, 02:36 ]
Post subject:  Re: Assert in egTexture.cpp loading DDS
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.
Author:  craigomatic [ 02.02.2010, 04:41 ]
Post subject:  Re: Assert in egTexture.cpp loading DDS
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:

Attachment:
h3d-assert-debug-locals.PNG
h3d-assert-debug-locals.PNG [ 45.21 KiB | Viewed 24848 times ]


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

Code:
int resId = h3d.addResource((int)resourceType, resourceName, 0);

if (nullTerminate)
{
    ms.Position = ms.Length;
    ms.WriteByte((byte)'\0');
}

byte[] bytes = ms.ToArray();

bool isLoaded = h3d.isResLoaded(resId);

if (!isLoaded)
    h3d.loadResource(resId, bytes, bytes.Length);

return resId;


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.

Attachments:
ambientMap.zip [5.2 KiB]
Downloaded 1133 times
Author:  AcidFaucet [ 02.02.2010, 13:50 ]
Post subject:  Re: Assert in egTexture.cpp loading DDS
Code:
ms.WriteByte((byte)'\0');


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).
Author:  craigomatic [ 02.02.2010, 22:58 ]
Post subject:  Re: Assert in egTexture.cpp loading DDS
AcidFaucet wrote:
Code:
ms.WriteByte((byte)'\0');


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:

Code:
h3d.loadResource(resId, bytes, resourceName.EndsWith(".dds") ? bytes.Length - 1 : bytes.Length);


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.
Author:  AcidFaucet [ 02.02.2010, 23:10 ]
Post subject:  Re: Assert in egTexture.cpp loading DDS
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."
Author:  marciano [ 02.02.2010, 23:44 ]
Post subject:  Re: Assert in egTexture.cpp loading DDS
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).
Author:  DarkAngel [ 03.02.2010, 00:16 ]
Post subject:  Re: Assert in egTexture.cpp loading DDS
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).
Author:  craigomatic [ 03.02.2010, 03:08 ]
Post subject:  Re: Assert in egTexture.cpp loading DDS
Thanks marciano, null terminating fixes the issue.
Author:  marciano [ 03.02.2010, 22:12 ]
Post subject:  Re: Assert in egTexture.cpp loading DDS
DarkAngel wrote:
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).

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.
Author:  swiftcoder [ 04.02.2010, 02:34 ]
Post subject:  Re: Assert in egTexture.cpp loading DDS
marciano wrote:
DarkAngel wrote:
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).
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?
Author:  marciano [ 10.02.2010, 01:02 ]
Post subject:  Re: Assert in egTexture.cpp loading DDS
swiftcoder wrote:
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?

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.
Page 1 of 1 All times are UTC + 1 hour
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/