Gfx9000 Library

Pagina 4/9
1 | 2 | 3 | | 5 | 6 | 7 | 8 | 9

Van Arjan

Paladin (697)

afbeelding van 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)

Van Arjan

Paladin (697)

afbeelding van Arjan

21-01-2004, 16:25

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

Van Grauw

Enlighted (8068)

afbeelding van 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.

Van anonymous

incognito ergo sum (109)

afbeelding van 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.

Van Grauw

Enlighted (8068)

afbeelding van Grauw

21-01-2004, 16:30

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

~Grauw

Van anonymous

incognito ergo sum (109)

afbeelding van anonymous

21-01-2004, 16:33

patience, patience ... Smile

Van ro

Guardian (4083)

afbeelding van 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)

Van snout

Ascended (15187)

afbeelding van 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.

Van anonymous

incognito ergo sum (109)

afbeelding van 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.

Van ro

Guardian (4083)

afbeelding van 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

Pagina 4/9
1 | 2 | 3 | | 5 | 6 | 7 | 8 | 9