A BITMAP FILE SPECIFICATION FOR THE X16. (1.0 is published)

[ahenry3068]

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.

We discussed a lot of this in the main thread on DISCORD. https://discord.com/channels/5475596260 ... 0908092416 I completely agree in principle. The problem is making it a formal definition (something like the document I've published here for BMX) I personally don't have enough knowledge of Tilemaps and Sprites to write that definition. If anyone would like to submit something I'm more than open to it. I still personally think it should be a different format (even if closely related) maybe even 2 file formats, 1 for Sprites and 1 for Tilemaps. (Maybe .SMX and .TMX)....

[AndyMt]

I still personally think it should be a different format (even if closely related) maybe even 2 file formats, 1 for Sprites and 1 for Tilemaps. (Maybe .SMX and .TMX)

I have the same feeling. Yes, we could try to create a general-purpose format for "all kind of things which contain pixels and sometimes also (parts of) a palette". But that would complicate converters and loaders/viewers. We've already seen what pitfalls there are even with this simple format to make it compatible with all converters/loaders/viewers etc.
I'm glad we have a file format for bitmaps (mostly full screen images) now, which I will actively support in my games and other software.

For tilesets (not tilemaps, that's something different) and spritesets I think we should define a different format, which doesn't contain a palette, but some other fields instead.
In the case of tilesets that would be like "tileSetDimensions", "tileIndexStart" and "tileCount" etc..
For spritesets there can be an entire discussion, wheter all sprites need to have the same dimensions per file, or if it is a list of sprites, for each of which you would have to define dimensions, bits per pixels, mirroring, palette offset, pixel data offsets etc. Would you have those parameters in one list and then all pixel data. Or would you have them mixed - so parameters for one sprite and then it's pixel data, then repeat?

I suggest to have the detailed discussion on the Discord thread.

[mgkaiser]

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.

We discussed a lot of this in the main thread on DISCORD. https://discord.com/channels/5475596260 ... 0908092416 I completely agree in principle. The problem is making it a formal definition (something like the document I've published here for BMX) I personally don't have enough knowledge of Tilemaps and Sprites to write that definition. If anyone would like to submit something I'm more than open to it. I still personally think it should be a different format (even if closely related) maybe even 2 file formats, 1 for Sprites and 1 for Tilemaps. (Maybe .SMX and .TMX)....

What I proposed doesn't require us to understand what is required for additional formats yet. It just defines the ability to add additional metadata blocks. We can figure it out later. Somebody else can figure it out later. Or the extended blocks can be used for some purpose that none of the forum have even thought of yet.

[Johan Kårlin]

I have just updated X16PngConverter (viewtopic.php?t=6345) to version 1.1. It now supports converting images to the new format. It can also generate a BASIC program that loads and displays the converted image.

[ahenry3068]

I have just updated X16PngConverter (viewtopic.php?t=6345) to version 1.1. It now supports converting images to the new format. It can also generate a BASIC program that loads and displays the converted image.

Thanks for being onboard. .

[desertfish]

Here's a Python script to create, display, and convert BMX images.
It does image rescaling if required and can optionally preserve the first 16 palette entries.
It requires the `pillow` package to be installed into your python environment to be able to read/write image files.

Usage should be pretty self explanatory. Run `python bmx.py -h` to display some basic help.

Note: because .py is not allowed as file extension for attachments, You have to rename the .txt to .py after downloading.