Gheh, well, just that whenever I want to make a file format with an ID, 4 characters usually is usually the best fit for the description .

Uh... FM-PAC also has two 4-byte ID's... (PAC2 and OPLL)... Gheh... ^_^


~Grauw

Yes, but PNG files, they're just not do-able. Mainly because of one reason: it doesn't support 15-bit RGB, the spec says in that case it has to be converted to 24-bit RGB and the compression will take care of the space waste. However I don't think either mandatory compression or ultra-large files are an option .

I was kidding about the PNG.. mentioned it mainly because of the IRC discussion yesterday (or was it this morning ^^

Anyway... a PNG viewer for MSX is still very much needed..

Well, 'very much' would be a bit exaggerated... Anyways, it shouldn't be hard to make.

~Grauw

Dude, I'd kill for a PNG viewer/convertor.
Then I finally wouldn't have to work with crappy BMP or GIF anymore...

Well, make it then... it's just a matter of a gzip decompressor iirc, of which sources should be easy to find, reading out some headers, and shifting some bits of the 8-bit colour channels into 5-bit... You could accept only 24-bits bitmaps.

~Grauw

You think I have time for that huh ^^;

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

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.

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

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.

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

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

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


Cheers ,

~Grauw

yay

cool