Gfx9000 Library

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

Van anonymous

incognito ergo sum (109)

afbeelding van anonymous

19-01-2004, 23:06

You think I have time for that huh ^^;

Van msd

Paragon (1372)

afbeelding van msd

20-01-2004, 09:09

The G9B support is almost finished.

I've added 3 functions for it.

G9kOpenG9B, returns an object containing the header information.
G9kReadG9B, read the file to Vram. X and Y can be specified and also
a palette offset can be given so you select the palette destination (very handy in P1,P2 I think)
G9kCloseG9B, Closes the file handle eof the G9B object

Van BiFi

Enlighted (4348)

afbeelding van BiFi

20-01-2004, 10:05

If you want to be able to display PNG's on MSX, you should display all color depths, not just 2, 4, 8, 16, 24, 32 or whatever supported in PNG.

Van ro

Guardian (4086)

afbeelding van ro

20-01-2004, 10:59

MSD,

You could add a 'execution' code header at the beginning of the file. If it is compressed (and the decompressor is build in) it can be decompressed by executing it.

Add a 'filetype' thingy in the ID header, and a 'compressor type' too.

Important is to add a byte/word telling how long the actual header is. (in case of variable header length)
(think of info blocks, source arrays etc... they COULD be added, not necessary. but would make it variable at least...)

oh, could you send me an example screen so I can test our RT cruncher for it's ratio on these files. kinda curious

Van msd

Paragon (1372)

afbeelding van msd

20-01-2004, 11:36

It already has a file type ID and a field that indicates compression. Different values could be used to indicate different compression methods. I've a palette size and data size in the header, but indead it could be wise to add a header lenght after the ID field.
I will send you some screen shots in different modes.. YUV and 15bit. you probably already tested it with 4 bit data? Adding the compressing routine in the file is a nice idea too. Will think about that.

Van ro

Guardian (4086)

afbeelding van ro

21-01-2004, 15:15

about compression:
There should be a standard, which is used already that could be implemented. But b'coz of the 'cruncher type id' it could be any existing one. (sometimes it's handy to include the decruncher in the crunched file, think of autoexecution)
http://www.nqpaofu.com/moerstaal/mtnl2000/mtnl-natcult.html for the picture

I've done a test with RT (redundancy terminator, (c) fuzz)
RT crunch report (pc versie 4 msx) for fire.g9b (test file included in the lib):
- Crunchformat : <rt> Normal datafiles
- Memory allocations : Ok
FIRE.ORG 126671/217104
(58.34% : 1 sec)
Total crunch time: 1 seconds.

from 217k to 126k which is about 50% (same as ZIP which packed it to 110k). Concidering this is a 'heavy' picture, RT did a very good job

other tests? (bitbuster etc)
more about comp.: http://thorkildsen.no/faqsys/cates/compress.html

Van Grauw

Enlighted (8084)

afbeelding van Grauw

21-01-2004, 16:16

TNI Compression Format (courtesy Guyver)
=============================

FIRE.G9B: 217104 bytes
FIRE.TCF: 117495 bytes

Cheers Smile,

~Grauw

Van anonymous

incognito ergo sum (109)

afbeelding van anonymous

21-01-2004, 16:16

yay Tongue

Van ro

Guardian (4086)

afbeelding van ro

21-01-2004, 16:18

cool

Van Grauw

Enlighted (8084)

afbeelding van Grauw

21-01-2004, 16:19

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!)

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