narahiero / ctlib Goto Github PK

When adding entries out of order, the file data offsets in U8/Write.cpp gets mixed up, and causes data corruption.

This bug will be fixed in the next commit.

The stb_dxt.h library does not use the exact same DXT1 format as the CMPR format. The biggest issue was the color palette being written as little endian instead of big, but I already fixed that.

The main difference now is that stb_dxt does not seem to care about the c1 < c2 transparency rule, resulting in pixels being invisible when they should not. Here is an example:

Original:

CMPR encoded:

So one possible fix I'm thinking of at the moment is to ignore transparency altogether and swap c1 with c2 if c1 < c2.

Since each octree node has a maximum number of triangles it can contain, the nodes sometimes needs to be split into 8 smaller nodes. This logic works most of the time, but if there are more triangles than the max node capacity in an area that is 2 times the blow factor on each axis, the nodes will split over and over again, never able to get small enough to satisfy the maximum triangle requirement.

The fix to this problem is to add minimum node size, and ignore the max triangle count if that limit is reached. That will entirely prevent that problem from happening.

However this issue is not that big of a deal, since any custom track having that many triangles in a small area is very likely to cause a slow motion bug.

While testing SZS creation (U8 archive compressed with Yaz0), I was taken aback by how slow the compression was. I tested some other programs and they all took much less time to compress the same data.

Here is a table of the stats of some tools when compressing the same data (6,034 KB).

As you can see, Wiimms SZS Tools compresses as well as CT Lib, but is 10 times faster.

So the algorithm definitely needs some improvements. One enhancement I can think of right off the bat is to use raw pointers instead of a buffer, as it does bounds checking on every put/get operation.

Another issue I stumbled upon while testing SZS creation (See issue #1) was this really strange glitch. When reading some U8 archives, some of the entries were located inside a directory they shouldn't have been in.

Upon further investigation, I realized that it only happened when both a directory node and its parent ended on the same node, that is, when the first node out index of both are equivalent. That, however, does not apply when the first node out index is the same as the root node's.

My guess would be that this troublesome problem is caused by the code between the lines 213 and 217 at the point in time this issue was opened. Here's a little preview of it:

if (i >= dir.size) // exit current directory
{
    dir = nodes[dir.offIdx];
    parent = parent->getParent();
}

Here the code only goes up once in the directory structure, causing the following entries to be part of the parent of the previous entry.

Replacing the if statement with a loop of some sort could fix the problem, but I have not tested it yet.