Well I'm a little late. We published this on DISCORD yesterday and I told Desertfish I would have it up last night.
But better late than never so. Here is the final specification 1.0 for BMX files.
How we handle LZSA compressed Data is a little up in the air, and at some point there will be an addendum for that. But it's not going to effect file structure, it will only effect the Compressed Image Data Block. For 90% of files where we aren't using compression everything will remain unchanged.
Regarding COMPRESSED ... perhaps rename it to FLAGS or something more generic, then specify that bit 7 means compressed, and bits 6-0 are reserved (you could use them for other flags in future versions).
I'll also use the general format for tile and sprite sets, there's no reason the basic process of having a 32 byte header that's loaded first into RAM, then data blocks that are loaded subsequently into VRAM can't work for bitmaps, tile sets, and sprite sets.
I'm a little dubious about the need for compression, considering the maximum size that can fit into VRAM would load uncompressed in under 2 seconds. But leaving it in doesn't hurt anything.
I believe the idea is that there will be a separate file format for sprite and tile data.
Or! maybe it'll become clear whether or not a few extra header fields will do the trick and no new file format is needed for it
Daedalus wrote: ↑Sat Dec 02, 2023 8:23 pm
Just to add... I'm going to put the "Number of frames" for sprite and tile sets as a 16 bit littleendian number in the first 2 bytes of reserved data.
Daedalus, If you think this format would work well for Tile and Sprite data we are more than happy to hear about it. One of the reasons we left Sprite & Tile Data out of the initial spec is because none of us on the discussion thread could really agree on what needed to be in the header to represent them. If you have something you think will work it would be helpful if you could write a draft spec for what you want and post it here or on the Discord thread for this subject. I'm all for having a version 2.0 of the spec Jan 2024 if we have a good formal way to include the data.
As a developer you have to do what makes your software work, but our idea of the format was to make it "standard" so I would hope that a lot of forks in the design don't happen, I would rather roll additional features into the formal spec.
Anyway. The only real addition needed for sprites and tiles is the number of tiles in the file. Which... is what the reserved data is for, is it not?
There are other considerations unique to sprites and tiles... specifically dealing with palette and animation data. Palette data is covered in the current file spec with a number of specific palette entries this file wants and the positions they go it. However. I feel that sprites and tiles should be palette agnostic, meaning that should be handled by a dedicated "project palette" that is included with the project that handles the run time needs. But "simple applications" that need only minimal insertions to the palette can be included... but probably shouldn't because of the "palette agnostic" nature of sprites and tiles. What I mean by that is... sure, a palette page can be set for the tile set or an individual sprite in real time, but that doesn't affect the data in the file, a 4bpp tile is 0-15 no matter what palette page it uses at run time.
As to animations, that is outside the scope of the sprite or tile's image data and should be in it's own file.
For sprites you would also need their size. They even can have different sizes, at least all my games have... And tiles can be 8x8 or 16x16 is I'm not mistaken. That's why we left all this out for this first release. I personally think for tile and sprite sets there will be separate formats which could follow a similar scheme as bmx.
The discord thread can be found in the 'video' channel.
Use one of the unused bytes in the existing header (or even a bit in that byte) to indicate that a secondary header is present. If this bit is set, the secondary header comes after the existing header and before the image data and contains any additional metadata required to describe sprites, tiles, etc. That way we retain this as a generic image format, but have the option of including additional metadata.
Perhaps we take it a step further and the first 3 bytes of the additional metadata are a flag that says there's even MORE metadata, the size of the metadata block and and id byte to indicate what kind of metadata. That way the format remains extensible for future use. Any given reader just skips the metadata blocks it doesn't care about.
SPEC_FOR_X16_BITMAP_FILE_Version 1.0.pdf
