While delving into routines to load and show various image file formats (koala, pcx, png, iff, bmp) it occurred to me that none of them particularly suits the Cx16.
Koala images are very specifically tied to the way the Vic-II in the C64 does graphics, and require a lot of conversion logic
Bmp contains a lot of Windows clutter and is always large and uncompressed
Pcx is always compressed and requires cpu power to decode (although that looks to be simple and the file format has little other overhead)
Png is a complex beast and requires a zlib deflate uncompressor
IFF is almost universally tied to the Amiga's bit-plane graphics and requires bit fiddling logic to decode
So I thought why not create a new image file format that is optimized for images that are meant to be displayed on the Cx16?
Currently I'm leaning towards the almost universal approach of having one file consisting of a header with meta data about the image, then the palette data, followed by the actual bitmap data. This looks to be convenient and with the appropriate fields in the header can be quite flexible as well to allow for various sizes, color depths and such.
However there are a few issues with this approach:
it does require the file to be loaded sequentially byte-by-byte, and this process is relatively slow compared to reading whole files at once using the LOAD kernel routine or the VLOAD basic command. Also unfortunately, reading the file sequentially only seems to work in the emulator when the file is on an sdcard image, which is a bit inconvenient compared to just reading it from a directory.
So I was thinking:
you could either VLOAD the file but taking into account that the bitmap data is preceded by several hundred bytes of header and pallette, and so use an adjusted load adress (but potentially overwriting other memory with that data).
Or perhaps split the file in three parts: metadata, palette, bitmap. Each can then be loaded as desired with just a regular LOAD/VLOAD call.
Any thoughts about the above ideas?
Could the difference in loading times perhaps be explained by the fact that I am using the emulator with its tweaked load routines?
VLOAD of an image is only possible when the image is exactly the width of the screen I think? If it is smaller or larger it will be displayed scrambled I suspect
PS. I'm currently only investigating pure bit map images. I have zero knowledge about the VERA's tile based display capabilities but would very much like to include them into this format if at all possible.
While delving into routines to load and show various image file formats (koala, pcx, png, iff, bmp) it occurred to me that none of them particularly suits the Cx16.
So I thought why not create a new image file format that is optimized for images that are meant to be displayed on the Cx16?
Currently I'm leaning towards the almost universal approach of having one file consisting of a header with meta data about the image, then the palette data, followed by the actual bitmap data. This looks to be convenient and with the appropriate fields in the header can be quite flexible as well to allow for various sizes, color depths and such.
However there are a few issues with this approach:
it does require the file to be loaded sequentially byte-by-byte, and this process is relatively slow compared to reading whole files at once using the LOAD kernel routine or the VLOAD basic command. Also unfortunately, reading the file sequentially only seems to work in the emulator when the file is on an sdcard image, which is a bit inconvenient compared to just reading it from a directory.
So I was thinking:
you could either VLOAD the file but taking into account that the bitmap data is preceded by several hundred bytes of header and pallette, and so use an adjusted load adress (but potentially overwriting other memory with that data).
Or perhaps split the file in three parts: metadata, palette, bitmap. Each can then be loaded as desired with just a regular LOAD/VLOAD call.
Any thoughts about the above ideas?
Could the difference in loading times perhaps be explained by the fact that I am using the emulator with its tweaked load routines?
VLOAD of an image is only possible when the image is exactly the width of the screen I think? If it is smaller or larger it will be displayed scrambled I suspect
PS. I'm currently only investigating pure bit map images. I have zero knowledge about the VERA's tile based display capabilities but would very much like to include them into this format if at all possible.
Share this post
Link to post
Share on other sites