PNG file convertor for VERA image data V1.6

[pastblast]

UPDATED to V1.6!

The program now supports 1/2/4/8 bits-per-pixel in the output, plus allows you to designate specific palette offsets in the output palette, for files not using 8 bits-per-pixel. As always, the generated palette has 12-bit entries (plus the extra 4-bit unused portion, required by VERA).

This version fixes the VRAM map issue when using the '-n' option. An example is:

Code: Select all

	/home/curtis/x16/image2binary/target/release/image2binary \
	 -w 64 -h 32 -a mb alpha-tile-map \
	 -w 64 -h 32 -a mb image-tile-map \
	 -b 4 -p 11 -a tb f-blue.png \
	 -b 4 -p 12 -n -a tb f-green.png \
	 -b 4 -p 13 -n -a tb f-red.png \
	 -b 4 -p 14 -n -a tb f-yellow.png \
	 -b 4 -p 15 -n -a tb f-white.png \
	 -a tb brdtiles.png \
	 -a sp seq08.png \
	 -a sp seq16.png \
	 -a sp seq32.png \
	 -a sp seq64.png  >SEQ.LOG

Here is the list of updates:

V1.0 - initial upload
V1.1 - output file path fix
V1.2 - include 2 zero bytes in front of binary image data
V1.3 - support creating VRAM memory map
V1.4 - output 2 extra files when image crosses VRAM page boundary
V1.5 - support 1, 2, 4, and 8 bits per pixel in output, plus specifying palette offsets
V1.6 - fix issue in VRAM map when using '-n' option


This program inputs PNG (24-bit RGB or 32-bit RGBA) files, and converts them into binary data for VERA. It consolidates the needed palette information across multiple files into a single palette, and provides that data as output, too. The intent is to be able to prepare multiple images, tiles, and/or sprites for display on the X16.

Starting with version 1.3, the program will create a VRAM memory map by attempting to fit the various output binary images into the VRAM memory space. They may be reordered, when compared to the order of the files listed in the command line. This feature also allows you to specify the required memory alignment for any of the input files, and you can include entries for the tile maps, which may be used for VERA Layer 0 and/or Layer 1. The program knows the particular alignments of tile maps, tile data, sprite data, and bitmap data, so you can easily indicate those things in the command line. Below is an example of an output VRAM map, computed by the program. The "Start" addresses can be used in code (BASIC or assembler) when loading file data into VRAM. See the "samples" directory in the repository for more information, particularly the log file there, and the one in the samples/alignment directory.

Here is the command line that was used to process the samples/alignment files, which resulted in the memory map below. Also, I have attached a screenshot from a test program that displayed data from the files, meaning that it showed the "board" background (as tiles) on Layer 0, the text "A" (as tiles) on Layer 1, and 5 sprites (4 spinning apples and 1 stationary apple). It does not show the monochrome image, because that feature is new.

Code: Select all

cd alignment
../image2binary \
 -w 64 -h 32 -a mb alpha-tile-map \
 -w 64 -h 32 -a mb image-tile-map \
 -a tb abctiles.png \
 -a tb brdtiles.png \
 -b 1 -p 15 monochrome.png \
 -a sp seq08.png \
 -a sp seq16.png \
 -a sp seq32.png \
 -a sp seq64.png  >alignment.log

And here is the resulting map.

Code: Select all

VRAM Address Arrangement

Waste Start  End    Size  Align Width Height Path/Name
----- ------ ------ ----- ----- ----- ------ ----------------------------------
    0 $00000 $00fff  4096   512    64    32  alpha-tile-map
    0 $01000 $01fff  4096   512    64    32  image-tile-map
    0 $02000 $0a2ff 33536  2048    16  2096  brdtiles.png
    0 $0a300 $0aeff  3072    32    16   192  seq16.png
    0 $0af00 $0af19    26     1    13    13  monochrome.png
  230 $0b000 $0feff 20224  2048    16  1264  abctiles.png
    0 $0ff00 $1beff 49152    32    64   768  seq64.png
      $0ff00 $0ffff   256                    SEQ64P0.BIN
      $10000 $1beff 48896                    SEQ64P1.BIN
    0 $1bf00 $1eeff 12288    32    32   384  seq32.png
    0 $1ef00 $1f1ff   768    32     8    96  seq08.png

NOTE: one output image crosses the VRAM page boundary, so there are now two
      extra output files, for loading the data in two sections, if needed.

The 2 extra output files (SEQ64P0.BIN and SEQ64P1.BIN) may not be needed, because the file loading function in ROM appears to be able to cross the 64K boundary in VRAM. So, ignore those extra files, if you don't need them.

Please see the README file in the repository, as it provides much more information.

https://github.com/TurboVega/image2binary

If you have any questions, or issues, please let me know. Thanks!

[pastblast]

Uploaded a small fix, yielding V1.1 of this tool. The code was converting the entire output file path to upper-case, rather than just the last portion (filename plus extension) of it. With the change, the first portion of the path is left as-is. FYI.

[pastblast]

I didn't realize that the 2 dummy address bytes needed to be at the front of the output binary image files, in order to load them with the VLOAD command in BASIC. I have modified the program to insert those 2 zero bytes at the head of the binary image data, so those ".BIN" files will also have an extra 2 bytes in them.

The output binary palette file already had (and still has) those 2 leading bytes.

This results in V1.2 of the app. Sorry for any confusion or issues, if you've tried this app.

[kelli217]

I didn't realize that the 2 dummy address bytes needed to be at the front of the output binary image files, in order to load them with the VLOAD command in BASIC. I have modified the program to insert those 2 zero bytes at the head of the binary image data, so those ".BIN" files will also have an extra 2 bytes in them.

The output binary palette file already had (and still has) those 2 leading bytes.

This results in V1.2 of the app. Sorry for any confusion or issues, if you've tried this app.

Seems like a pretty cool project... posterizing, quantizing, whatever you want to call it.

[pastblast]

Thanks! I'm using it in a game project. There are 25 directories with images involved. Each directory has images for sprites and tiles. The tool computes the palette for each directory, such that all of its images can appear on the screen using a single palette. So, there are 25 palette files, plus over 100 image binaries. Directories will be used for distinct game levels.

[Roy Eltham]

Lot of good features in this one, nice work!

It would be cool if you made it so that the 2 byte header thing on all the output files was able to be turned off with an option.
There are basic commands and kernel calls for loading without them now (e.g. BVLOAD and BLOAD).

[ahenry3068]

I don't know if you saw it but I wrote this.

viewtopic.php?t=6782&start=20

It can convert almost any Image to BVLOAD format. (full screen 320x240, not tiles)