Gfx9000 Library

Página 4/9
1 | 2 | 3 | | 5 | 6 | 7 | 8 | 9

Por Arjan

Paladin (770)

imagem de Arjan

21-01-2004, 16:23

TCF rules! if only it would be opensource...
bitbuster does slightly worse than RT, 126704 bytes (time to add variable length offsets Tongue)

Por Arjan

Paladin (770)

imagem de Arjan

21-01-2004, 16:25

winzip does better, 111292 bytes (111406 bytes for the while zip)

Por Grauw

Ascended (10605)

imagem de Grauw

21-01-2004, 16:27

Top 6 list so far:

1. FIRE.ZIP: 110100 bytes (107,5k) (WinRar - best compression)
2. FIRE.RAR: 114046 bytes (111,4k) (WinRar - best compression)
3. FIRE.TCF: 117495 bytes (114,7k)
4. FIRE.RT: 126671 bytes (123,7k)
5. FIRE.BB: 126704 bytes (123,7k)
6. FIRE.G9B: 217104 bytes (212,0k)

~Grauw

p.s. funny btw that winrar does better at zip than winzip.

Por anonymous

incognito ergo sum (116)

imagem de anonymous

21-01-2004, 16:29

TCF is not yet finalized, so that's one of the reasons it's not open source at the moment.

Por Grauw

Ascended (10605)

imagem de Grauw

21-01-2004, 16:30

For instance there is no MSX cruncher yet... grmbl... Smile

~Grauw

Por anonymous

incognito ergo sum (116)

imagem de anonymous

21-01-2004, 16:33

patience, patience ... Smile

Por ro

Scribe (4714)

imagem de ro

21-01-2004, 16:42

And mind you: this is a speed-oriented compression format, meant for use in games, etc. Just like BitBuster and (I guess) RT. So no fair comparing with RAR or the likes! ;p

~Grauw

p.s. RAR: 114046 bytes. (and this is 'best compression'! Pah!)

It was build with that in mind yeah. RT is a redundancy checker and is therefor a bit slow at compression, but REALY fast at decompressioni (using already decomped blocks) Although it could be faster 'coz of the build in 16k. block max. This was done due limited memory spill (the Kernel has 1 standard temp. buffer for things like: decompression, sample transfer, music decomped from ramdisk, file transfer for ramdisk functions, temp. lib sources etc) (yep, RT is build in fKernel)
This limits the 'look-back' function (only 16k. remember) but at the time it was build, there were no 'over 16k. (comped) files' like gfx9000 data. So in practise the overall speed of RT (on typical msx files) is mostly at max.

oh , RT uses 3 typical types of compression format:

0, decrunch (multiple blocks) to RAM (normal mode, use for any file)
1, decrunch to VRAM using direct VDP access
2, decrunch to VRAM using RAM->VRAM block transfer
3, DD-Graph *.DAT files (Crunched as type 2)
4, Graph Saurus *.SR? files (Crunched as type 2)

Type 2 is for x1,y1-x2,y2 blocks of video data (blocks, non linear vram data)
Also pallette data can be included.
There were MSX and PC (de)compressors coded

The fire.g9b was done with type 0 (any file) (comped on PC)

Por snout

Ascended (15187)

imagem de snout

21-01-2004, 16:46

Maybe we should do a little benchmark as well, with the file formats that can be decompressed on MSX. I'd like to know how long it takes a Z80 or an R800 to extract these files.

Por anonymous

incognito ergo sum (116)

imagem de anonymous

21-01-2004, 16:46

TCF can currently directly decompress to VRAM too. Also, it can decompress directly from disk, without loading the compressed file into memory.

Por ro

Scribe (4714)

imagem de ro

21-01-2004, 16:50

TCF can currently directly decompress to VRAM too. Also, it can decompress directly from disk, without loading the compressed file into memory.

But that would slow down the decompresion time.
RT (the kernel version) loads blocks of data of max.16k directly from disk (so it's transparant for users, just point out the filename and kernel will get it.. crunched or not: here you have the data you requested, sir)

ps. maybe a new forum topic for cruncher benchmarks etc

Página 4/9
1 | 2 | 3 | | 5 | 6 | 7 | 8 | 9