[continued from previous message]
Can note that 1C (after unpacking the Deflate compression) used an
encoding scheme sorta like (if looking at bytes), IIRC:
00..7F: First byte of a raw block, 8 bytes.
Consisted of two RGB555 values, big endian, and a 4x4x2 pixel block.
For DXT1, needed to be turned to RGB565 LE.
Pixel block was also BE and different from DXT1,
but an easy enough fix (with lookup tables), and shift+or.
In RPZA, could escape to 16x RGB555 colors, but was not used in 1C.
80..9F: 1-32 skip blocks (kept as-is from last frame)
A0..BF: Flat Color, RGB555 value.
C0..DF: Two RGB555 colors, 1-32 4x4 blocks sharing the same colors.
E0..FF: Used for something...
I forget ATM, maybe skip+translate.
At top-level, would indicate the use of TLV packaging.
Otherwise, frame would be decoded as a raw command stream.
IIRC, there was an option to encode a separate alpha layer (for decoding
to DXT5). Another option was to encode the alpha similar to DXT1, namely
via color endpoint ordering, IIRC:
C0C1: 1-bit transparency.
Or, no alpha of either sort, in which case it was opaque.
No mipmaps were encoded here. Strategy was to use a quick/dirty approach
to rebuild mipmaps on the fly.
The followups, 1D and 1E, were intended to try to give better fidelity
when decoding to BC7, but mostly failed to be all that fast.
By 1H, had switched to one-off command-tag codes, with colors being
delta-coded and blocks reusing prior colors. Worked OK as it was built
around Rice coding everything. This format was significantly more
complicated.
For 5A/5B, had instead used a unary-coding scheme to encode commands
(similar to both QOI and RP2).
By the second engine, I had mostly stopped using video textures, and was
instead using shader effects to do some animations (with a static
atlas). In the shaders, I ended up mostly using dithering for the alpha
as I sorta liked this effect at the time over the more traditional
translucency effects.
IIRC, was using a 2048x2048 atlas in this case (for 128x128 pixels per
block).
For my 3rd engine, it dropped it again to 1024x1024, with each block
texture limited to 64x64. No shaders as this engine was written to
assume being limited to roughly OpenGL 1.3 features.
Instead it redraws all the water blocks and similar using Quake-style ST
warping (but only for blocks near the camera).
If I were to bring back video textures, could maybe use 1C or 5B as a
base, though if using 1C may modify it to allow for RP2 and TKuLZ,
mostly because of the whole "Deflate is kinda slow" issue.
Ironically, it seems the only reason 1H seemed fast may have been
because it was faster than Deflate; but by my current standards Deflate
isn't all that fast.
> Experimented some with LZ4 and Huffman encoding. Huffman used for ECC
> logic.
>
Yeah. LZ4 works.
I am mostly using it for PE/COFF compression, as it seems to do much
better in this case.
For data compression, mostly ended up with my own custom RP2 design as
it mostly beats LZ4 in terms of compression, and is similarly fast.
Which is better mostly depends on the data in question though...
In a few cases, I had STF+AdRice based LZ compressors, but these mostly
make sense if the file being compressed is fairly small (lower end of
the kB range).
But, RP2 also works well for small data.
Whereas, both TKuLZ and Deflate need larger data (say, over 16K-64K) to
be effective (if compressing chunks of data in single-digit kB or less,
Deflate kinda sucks...).
>
>
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
