JSquish - DXT Compression Library

Shared Code
#21

[quote=“pepijnve,post:18,topic:28640”]
Thanks a lot pepijnve, it was indeed a bug and fixing it improved performance considerably. I wonder why such a bug didn’t have any effect on the compression quality though. Anyway, I have updated the library archives.

[quote=“pepijnve,post:20,topic:28640”]
Great! Could you tell me how JSquish performs under your benchmark?

#22

103ms. The difference is due to a reordering of some of the code. I rearranged things so for each image I only have to make a single instance of SingleColour, Range and ClusterFit. These methods have a reset method to intialize any fields now. It’s not pretty but it produces less garbage. I chose this approach over your approach of making most of the fields static because I wanted to be able to compress multiple images in parallel.

#23

First of all, thank you for porting this to java - we’re now using DXT for most of the Tribal Trouble textures. However, I think decompressing DXT in jsquish is broken, since ColourBlock.unpack565() doesn’t account for the byte sign properly. I’ve changed unpack565 to:


    private static int unpack565(final byte[] packed, final int pOffset, final int[] colour, final int cOffset) {
        int b1 = packed[pOffset + 0 + cOffset * 2] & 0xff;
        int b2 = packed[pOffset + 1 + cOffset * 2] & 0xff;
        // build the packed value
        int value = b1 | b2 << 8;

        // get the components in the stored range
        int red = (value >> 11) & 0x1f;
        int green = (value >> 5) & 0x3f;
        int blue = value & 0x1f;

        // scale up to 8 bits
        colour[0 + cOffset * 4] = (red << 3) | (red >> 2);
        colour[1 + cOffset * 4] = (green << 2) | (green >> 4);
        colour[2 + cOffset * 4] = (blue << 3) | (blue >> 2);
        colour[3 + cOffset * 4] = 255;

        // return the value
        return value & 0xffff;
    }

(adding masking to the two halves of the 565 color) which seems to fix this.

  • elias
#24

Thanks, I hadn’t tested decompressing.

#25

Shouldn’t

int b1 = packed[pOffset + 0 + cOffset * 2] & 0xff;
int b2 = packed[pOffset + 1 + cOffset * 2] & 0xff;

be

int b1 = packed[pOffset + 0] & 0xff;
int b2 = packed[pOffset + 1] & 0xff;

?

If not, why do you need to add cOffset * 2 to the packed offset?

#26

Dang. Any chance of a 1.4 compatible version? Or can the whole process be run offline and saved to a DDS or similar?

#27

Squish on its own only performs the DXT compression. The output is just a bunch of DXT blocks. It’s pretty straightforward to write these to a DDS file afterwards, so offline processing is definitely possible.

#28

[quote=“Orangy Tang,post:26,topic:28640”]
It could work on even older versions, but I’m too used to 1.5 features right now. :slight_smile: There are a couple of enums, some static imports and maybe some efor loops, you’re free to modify the source if you need it.

[quote=“pepijnve,post:25,topic:28640”]
You’re right, that was not optimal. I’ve uploaded the library + archives again.

#29

Update: Fixed a bug with GL_COMPRESSED_RGBA_S3TC_DXT1_EXT compression. Thanks to Daniel Senff.