In this forum I would like to start a discussion about the Ggfx9000 library. I will also post updates of this library in this treath from now on.

Then next release will support loading (and maybe saving) of graphical data in a new file format. I amlost finished a new version of v9bmp to convert data into this new format.
This format will be called Gfx9000 Bitmap .G9B. This format will accommodate all color modes of the gfx9000 and is not fixed to screen resolution. No existing format that I could find is sutable for this porpuse.

Is it compressed?

And if not, maybe you can make the format extendible so that compression (and all kinds of other stuff, like text information for say, a viewer) can be added to the format later on?

it definately needs some form of compression! it doesn't have to be as good as LZH, but I prefer a format which can be decompressed very fast. Something like bitbuster would be good or whatever format you think suits well...

I did not add compresssion. And also compressing yuv and 15bit pictures does nog work very good, but I will add a field that indicates if compression is used.

Also I have not decided yet if i store the bitdepth info as done in the gfx9000 itself or as done in most file formats.
So should I store 0,1,2 or 3 as bitdepth, which is easy to use because it can dan be direclty written in de gfx9000 or as 2,4,8,15?

The latter.

and what about palette mode. I could just throw them in the same byte
something like this

low nibble bitdepth
high nibble palatte mode

0=64 color palete
1=256 fixed
2=YUV
3=YJK
etc

Nah, make it two single bytes. It's easier to decode in assembly (shifting a nibble is ugly code, I think ), and one extra byte won't harm anyone.

compression with 15bit pictures can actually work quite good, as long as you don't compress digitized images. Most digitized pictures are YJK/YUV, so they don't really need compression, but still it would help a lot for drawn graphics. Also, including compression in the format itself is easier than having a separate tool to compress the graphics.

Well it's not that most digitized image are yuv/yuv, but we can save them in that format and that saves 50%.. always..
I will just add a field that indicates compression and later on it can be added.

btw arjan: I think we should use the yuv mode in 512*212(424) for intro stuf etc

YJK/YUV is VERY well compressible! Just split the Y part and the JK/UV part, that makes really good compression material.

Same counts for 15 bit images... Difference-compression works best for graphics, even better than general compressors like LZH or Bitbuster, or TCF...

The header of the format will look like this

G9B_ID DB "G9B"
G9B_BIT_DEPTH DB 0 ; 2,4,8 or 16
G9B_COLOR_TYPE DB 0
G9B_WIDTH DW 0
G9B_HEIGHT DW 0
G9B_COMPRESSION DB 0
G9B_DATA_SIZE DS 3,0 ; 24 bit file size
G9B_NR_COLORS DB 0 ; Number of colors in palette mode

Anyone something to add?

Well, I prefer 4-byte ID's, but that's just me, perhaps.

It probably is or do you have a good reason for it?

I prefer PNG files

They even have 4 byte ID's too