Git Product home page Git Product logo

convimg's Introduction

convimg Build Status Coverity Scan

This program is used to convert images to particular color formats and source includes. It primarily is used for the TI-84+CE and related calculator series, however can be used as a standalone program.

Command Line Help

Usage:
    convimg [options]

Optional options:
    -i, --input <yaml file>  Input file, format is described below.
    -n, --new                Create a new template YAML file.
    -h, --help               Show this screen.
    -v, --version            Show program version.
    -c, --clean              Deletes files listed in 'convimg.out' and exits.
    -l, --log-level <level>  Set program logging level:
                             0=none, 1=error, 2=warning, 3=normal
Optional icon options:
    --icon <file>            Create an icon for use by shell.
    --icon-description <txt> Specify icon/program description.
    --icon-format <fmt>      Specify icon format, 'ice' or 'asm'.
    --icon-output <output>   Specify icon output filename.

YAML File Format:

    A YAML file is a human-readable text file that is used by this program
    to create palettes, convert images, and output the results to a supported
    format. A palette is a list of colors that an image or group of images uses.
    This saves memory by having a fixed number of colors rather than storing
    a color for every pixel in the image.

    The YAML file consists of three key components: palette generation, image
    conversion, and output formatting. These components are broken down into
    different sections of a YAML file, shown below:

        palettes:
          - name: mypalette           : Palette and name of palette
            images: automatic         : Automatically get list of images

        converts:
          - name: myimages            : Convert images section
            palette: mypalette        : Use the above generated palette
            images:                   : List of input images
              - image1.png
              - image2.png
              - image3.png

        outputs:                      : List of outputs
          - type: c                   : Sets the output format to C
            include-file: gfx.h       : File name containing all images/palettes
            palettes:                 : Start of palettes list in the output
              - mypalette             : Name of each palette, separated by line
            converts:                 : Converted sections, based on name
              - myimages              : Name of each convert section

To create the above template, use the '--new' command line option.
By default 'convimg.yaml' in the same directory the program is executed
will be used for conversion - this can be overriden with the -i flag.
The following describes each section of the YAML file in more detail, and
the available options for conversion.

--------------------------------------------------------------------------------

palettes:
    The YAML palettes section constists of a list of different palettes to be
    generated. List entires start with the name of the palette to create.

     - name: <palette name>       : Name of palette. This is used by the
                                  : convert blocks for detecting which
                                  : palette to use, as well as the name
                                  : used in the output code files.
                                  : Required parameter.

       max-entries: <num>         : Number of maximum colors available
                                  : in the palette. Range is 2-256.
                                  : Default is 256.

       fixed-entries:             : Adds fixed color entries to the
                                  : palette. The format is:
                                  :
                                  :  fixed-entries:
                                  :    - color: {index: 0, r: 9, g: 10, b: 0}
                                  :    - color: {index: 1, r: 2, g: 83, b: 5}
                                  :    - color: {index: 2, hex: "#945D3A"}
                                  :    - color: {index: 3, hex: "#C54DCE"}
                                  :
                                  : Note the spaces between key/value pairs.
                                  : 'index' represents the palette entry
                                  : used for the color, r is the red amount,
                                  : g is the green amound, and b is the blue
                                  : amount of the color. This is often
                                  : called the "rgb" value of a color.
                                  : A quoted "hex" string beginning with '#'
                                  : can also be used instead.
                                  : 'exact' is used to match colors exactly
                                  : to the input color before quantization.
                                  : It is an optional parameter, defaults to
                                  : 'false' but can be 'true'.
                                  : Fixed entries can also be supplied via
                                  : an image, 1 pixel in height (and a
                                  : width <= 256) where each pixel in the
                                  : image represents an entry:
                                  :
                                  :   fixed-entries:
                                  :     - image: palette.png
                                  :
                                  : There can be up to 256 fixed entries.
                                  : With the image method, the starting
                                  : index is 0 and increments by 1 moving
                                  : from left to right.

       quality: <value>           : Sets the quality of the generated palette.
                                  : Value range is 1-10, where 1 is the worst
                                  : and 10 is the best. Lower quality may use
                                  : less palette entries.
                                  : Default is 8.

       images: <option>           : A list of images separated by a newline
                                  : and indented with a leading '-'
                                  : character. These images are quantized
                                  : in order to produce a palette that
                                  : best matches with these images.
                                  : <option> can be 'automatic' to
                                  : automatically get the images from the
                                  : convert blocks that are using them,
                                  : without having to specify the images
                                  : twice. Note that common "globbing"
                                  : patterns can be used, such as '*'.

--------------------------------------------------------------------------------

converts:
    The YAML converts section constists of a list of different "groups" of
    images to be converted that share similar properties, such as the palette
    used, or the compression mode. The available options are:

     - name: <convert name>       : Name of convert. This is used by the
                                  : outputs for detecting which converted
                                  : images to output.
                                  : Required parameter.

       palette: <palette name>    : Name of palette used to quantize images
                                  : against. This is the name of a palette
                                  : block. Built-in palettes also exist,
                                  : namely 'xlibc' and 'rgb332'.

       palette-offset: <index>    : Converts assuming a palette has
                                  : a different base index.
                                  : Defaults to '0'.

       images:                    : A list of images separated by a newline
                                  : and indented with a leading '-'
                                  : character. These images are quantized
                                  : against the palette.
                                  : Note that common "globbing"
                                  : patterns can be used, such as '*'.

       tilesets:                  : A group of tilesets. There can be only one
                                  : tileset group per conversion block.
                                  : Tilesets are special images consisting of
                                  : multiple "tiles" of fixed width and
                                  : height. The format for this option is:
                                  :
                                  : tilesets:
                                  :   tile-width: 16
                                  :   tile-height: 16
                                  :   images:
                                  :     - tileset1.png
                                  :     - tileset2.png
                                  :
                                  : Above, each tileset in the list is
                                  : composed of tiles of a width and height
                                  : of 16 pixels. Tile numbers are determined
                                  : starting from the top left, moving right
                                  : to the bottom-right.
                                  : Optional fields are:
                                  :   'tile-rotate': rotate tiles 90, 180, 270.
                                  :   'tile-flip-x': flip tiles across x axis.
                                  :   'tile-flip-y': flip tiles across y axis.
                                  :   'pointer-table': output tile pointers

       transparent-index: <index> : Transparent color index in the palette
                                  : that represents a transparent color.
                                  : This only is used in two cases!
                                  : When converting 'rlet' images,
                                  : or for assigning pixels in the source
                                  : image that have an alpha channel.
                                  : If the alpha chanel is 0 in an pixel,
                                  : the converted output will be assigned
                                  : this value.
                                  : Generally, you want transparency to be.
                                  : defined as a 'fixed-entry' color in the
                                  : palette instead of using this option.
                                  : Default is '0'.

       style: <mode>              : Style controls the converted format of
                                  : images. In 'palette' mode, converted
                                  : images map 1-1 where each pixel byte
                                  : represents a palette index.
                                  : In 'rlet' mode, the transparent color
                                  : index is used to compress runs of
                                  : transparent colors, essentially reducing
                                  : the output size if there are many
                                  : transparent pixels.
                                  : In 'direct' mode, the color format
                                  : defined by the 'color-format' option
                                  : converts the input image colors to the
                                  : desired format. This may prevent some
                                  : palette-specific options from being used.
                                  : Default is 'palette'.

       color-format: <format>     : In direct style mode, sets the colorspace
                                  : for the converted pixels. The available
                                  : options are 'rgb565', 'bgr565', 'rgb888',
                                  : 'bgr888', and 'rgb1555'.
                                  : Default is 'rgb565'.

       compress: <mode>           : Images can be optionally compressed after
                                  : conversion using modes 'zx0' or 'zx7'.
                                  : The 'zx7' compression time is much faster,
                                  : however 'zx0' usually has better results.

       width-and-height: <bool>   : Optionally control if the width and
                                  : height should be placed in the converted
                                  : image; the first two bytes respectively.
                                  : Default is 'true'

       flip-x: <bool>             : Flip input images vertically across the
                                  : x-axis

       flip-y: <bool>             : Flip input images horizontally across the
                                  : y-axis

       rotate: <degrees>          : Rotate input images 0, 90, 180, 270 degrees

       bpp: <bits-per-pixel>      : Map input pixels to number of output bits.
                                  : Available options are 1, 2, 4, 8.
                                  : For example, a value of 2 means that 1 pixel
                                  : in the input image maps to 2 bits of output.
                                  : The palette option 'max-entries' should be
                                  : used to limit the palette size for this
                                  : option to ensure correct quantization.
                                  : Default is '8'.

       omit-indices: [<list>]     : Omits the specified palette indices
                                  : from the converted image. May be useful
                                  : by a custom drawing routine. A comma
                                  : separated list in [] should be provided.

--------------------------------------------------------------------------------

outputs:
    The YAML file outputs section is a list of different "groups" of outputs,
    differing in types or images. The currently available formats are:

     - type: c                    : C source and header files
     - type: asm                  : Assembly and include files
     - type: bin                  : Binary and listing files
     - type: basic                : Single string formatted file
     - type: appvar               : TI archived AppVar format

    The different options available for outputs are:

       include-file: <file>       : Output file containing all the graphics
                                  : Defaults to "gfx.h", "gfx.inc",
                                  : "bin.txt", and "basic.txt" for C, Asm,
                                  : Binary, and BASIC formats respectively.

       palettes:                  : A list of generated palettes, separated
                                  : by a newline and indented with the '-'
                                  : character.

       converts:                  : A list of convert sections, separated
                                  : by a newline and indented with the '-'
                                  : character.

       directory: <directory>     : Supply the name of the output directory.
                                  : Defaults to the current directory.

       prepend-palette-sizes:     : Prepend the palette with a 2-byte
           <bool>                 : entry containing the total size in
                                  : bytes of the palette.
                                  : Default is 'false'.

       const: <bool>              : Only applicable to C outputs.
                                  : Adds the 'const' parameter to output types.
                                  : Default is 'false'.

   AppVars are a special type of output and require a few more options.
   The below options are only available for AppVars, however the above
   options can also be used.

       name: <appvar name>        : Name of AppVar, maximum 8 characters.
                                  : Required parameter.

       source-format: <format>    : Source files to create to access
                                  : image and palette data. format can be
                                  : 'c', 'ice', 'asm', or 'none'.
                                  : Default is 'none'.

       source-init: <bool>        : Whether to output AppVar initialization
                                  : code for loading and setting up image
                                  : and palette pointers. Default is 'true'
                                  : Only compatible with source-format: 'c'.

       lut-entries: <bool>        : Embeddeds a lookup table (LUT) for
                                  : determining the image offsets in the
                                  : appvar. Format consists of an entry
                                  : containing the table size, followed by
                                  : the LUT entries. Entry sizes are
                                  : controlled via the parameter
                                  : 'lut-entry-size'. Default is 'false'.

       lut-entry-size: <int>      : Controls the size of LUT entries. Can be
                                  : '2' for 2-byte or '3' for 3-byte entries.
                                  : Default is '3'.

       compress: <mode>           : Compress AppVar data.
                                  : Available 'mode's: 'zx0', 'zx7'.
                                  : The AppVar then needs to be decompressed
                                  : to access image and palette data.
                                  : Optional parameter.

       header-string: <string>    : Prepends <string> to the start of the
                                  : AppVar's data.
                                  : Use double quotes to properly interpret
                                  : escape sequences.

       archived: <bool>           : 'true' makes the AppVar archived, while
                                  : 'false' leaves it unarchived.
                                  : Default is 'false'.

--------------------------------------------------------------------------------

Credits:
    (c) 2017-2024 by Matt "MateoConLechuga" Waltz.

    This program utilizes the following libraries:
        libimagequant: (c) 2009-2022 by Kornel Lesiński.
        libyaml: (c) 2006-2022 by Ingy döt Net & Kirill Simonov.
        stb: (c) 2017 by Sean Barrett.
        zx0,zx7: (c) 2012-2022 by Einar Saukas.

convimg's People

Contributors

adriweb avatar banchor avatar commandblockguy avatar jacobly0 avatar legend-of-iphoenix avatar mateoconlechuga avatar myclevorname avatar petertillema avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar

convimg's Issues

AoCE gfx converting crashes

I used the latest convpng.ini from AoCE, but with this: Buildings/*/*_{1,2,3,4}.png instead of

Buildings/*/*_1.png
Buildings/*/*_2.png
Buildings/*/*_3.png
Buildings/*/*_4.png

No idea what went wrong :P

Rotated / mirrored converts

There should be a convert option for rotating and mirroring input images. It would be useful for alternate SPI modes, which can use a column-major memory layout.

Suggestion: Allow conversion to 16-bit color

I have been working on a library called ICERGB, which uses the full 65,636 colors.
It would be nice if you could make convpng have the ability to create sprites/images capable of displaying in 16-bit color mode.

Input files do not conform to YAML spec

According to the YAML spec,

The content of a mapping node is an unordered set of key: value node pairs, with the restriction that each of the keys is unique.

In convimg, in order to specify multiple outputs, palettes, converts, or fixed index colors, keys with duplicate values must be used, in violation of the spec.
For example, the following is a valid input for convimg, but not a valid YAML file:

output: c
  palettes:
    - palette1
    - palette2
  converts:
    - convert1
    - convert2

output: ice
  palettes:
    - palette1
    - palette2
  converts:
    - convert1
    - convert2

palette: palette1
  images: automatic
  fixed-color: {index: 0, r: 255, g: 255, b: 255}
  fixed-color: {index: 1, r: 0, g: 0, b: 0}

palette: palette2
  images: automatic
  fixed-color: {index: 0, r: 0, g: 0, b: 0}
  fixed-color: {index: 1, r: 255, g: 255, b: 255}

convert: convert1
  palette: palette1
  images:
    - *

convert: convert2
  palette: palette2
  images:
    - *

This could be fixed by replacing the mappings that use duplicate keys with a mapping of selections for each key type, as in the following example:

outputs:
  - type: c
    palettes:
      - palette1
      - palette2
    converts:
      - convert1
      - convert2
  - type: ice
    palettes:
      - palette1
      - palette2
    converts:
      - convert1
      - convert2

palettes:
  - name: palette1
    images: automatic
    fixed-colors:
      - {index: 0, r: 255, g: 255, b: 255}
      - {index: 1, r: 0, g: 0, b: 0}
  - name: palette2
    images: automatic
    fixed-color: {index: 0, r: 0, g: 0, b: 0}
    fixed-color: {index: 1, r: 255, g: 255, b: 255}

converts:
  - name: convert1
    palette: palette1
    images:
      - *
  - name: convert2
    palette: palette2
    images:
      - *

#FixedIndexColor exact color match

Title roughly explains the feature request. With this functionality, an input color must exactly match the specified color. This is useful in the case that a special input color maps to a palette color that may be changed dynamically at runtime. In this case, non-special pixels that may have similar input colors should not be mapped to this special color.

Suggested implementation: remove the seemingly unnecessary optional "alpha" parameter of #FixedIndexColor and replace it with an optional "exact match" boolean parameter, to trigger the new functionality.

Alternate implementation: create a new instruction #FixedIndexColorExact with the same parameters as #FixedIndexColor to provide the new functionality.

Putting multiple images in one file causes illegal macros

Edit: this is caused by issue #4
For example, the command
convpng -8zjh -i 1.png 2.png 3.png 4.png 5.png 6.png 7.png 8.png 9.png 10.png 11.png 12.png 13.png 14.png
puts all of the images in a file and calls it 1.h, but leaves:

ifndef 1_h

define 1_h

macros in between every image.

Tilesets don't work.

Trying to convert a tileset results in the tileset image being treated like a regular sprite.
The relevant part of my config file:

    tilesets:
      tile-width: 14
      tile-height: 5
      ptable: true
      images:
        - tileset.png

Based on the output, I think this is a parser issue - I think the images line causes the parser to exit the tileset mode. However, removing that line causes convimg to quit with [error] Failed to load image '(null)'

Output in ICE format

The ability to ouput in ICE format would be quite handy. It is simply a string of the array with no spaces or padding:

"0101FFFFFF...."

The first two bytes represent the width/height of the sprite respectively.

Proper glob

dir/*/*_3 for example should find all of it man.

convpng hangs when run on Raspbian Buster for Raspberry Pi 4

Title is self-explanatory.
Program displays author info, and then hangs. No convpng.log created, no terminal output.
I don't expect this to an easy fix or a priority one, but I have included the build directory as it was on my Pi, with the build files and output included, in case any of that helps with debugging.
convpng-master.zip

Option to remove transparent pixels in output

This is the right place to post this 'issue' :P
So basically, an option that you can ignore/remove the transparent pixels in the output, thus that you don't get a rectangular output in general. Is useful for people who use their own routine to display a non-rectangular sprite (like me).

Rust port

I want to rewrite convpng in Rust.

Palette can contain duplicate values when using fixed-colors

When using fixed-colors in a palette, a particular color can be chosen for the palette twice, once as the fixed color, and again as a quantized palette entry. This can be wasteful, especially for low bpp modes or with dynamic palettes.

Perhaps any pixels that exactly match a fixed color could be removed from the image when generating the quantized palette.

Relative/Absolute paths

Rather than a name; it would be nice if convpng supported wildcards and relative/absoulte paths you know :P

Error in appvar_init code when appvar compressed

This is related to #37 that I proposed a while back. In my specific project, my appvar is compressed, and the trekgui_init code looks like this.

bool trekgui_init(void *decompressed_addr) {
    unsigned int data, i;

    data = (unsigned int)decompressed_addr - (unsigned int)trekgui[0];
    for (i = 0; i < trekgui_num; i++) {
        trekgui[i] += data;
    }
    return (bool)appvar;
}

This is wrong because in this particular case, appvar does not exist. I propose fixing by mixing this with the code to open (and decompress) the appvar.

bool trekgui_init(void *decompressed_addr) {
    unsigned int data, i;
    ti_var_t appvar;
    
    appvar = ti_Open("trekgui", "r");
    zx7_Decompress(decompressed_addr, ti_GetDataPtr(appvar));
    data = (unsigned int)decompressed_addr - (unsigned int)trekgui[0];
    for (i = 0; i < trekgui_num; i++) {
        trekgui[i] += data;
    }
    ti_Close(appvar);  // ti_CloseAll()
    return (bool)appvar;
}

Needs an overhaul

The code is getting hard to read. I need to listen to my own advice and keep it simple stupid.

Export appvars

Can we please fix appvar exportation and add something to the toolchain to make it easy to read things? Thanks.

Allow TransparentIndex with Palette

Currently, when you use #Palette, both #TransparentColor and #TransparentIndex are ignored. It seems right to me that at least #TransparentIndex would be supported when using #Palette as well.

There is no OutputHeader command

Convimg does not contain a command that will allow the user to output a particular string header at the start of an Appvar. This would allow programs to easily search for an Appvar using Detect(). This was a command convPNG included but convIMG does not.

A way to create a palette that doesn't include the color used to indicate transparency for RLET sprites

[20:56:30] <Kryptonic> What's the point of having the color that was used to indicate a transparent pixel in the palette if using RLET sprites?
[20:59:58] <Pieman> What is the point of RLET sprites?
[21:00:06] <saxjax> [epsilon5] Compression.
[21:03:38] <Kryptonic> I'm trying to get convpng to make a palette that doesn't include the color I'm using to indicate transparency in rlet sprites, but I don't know if that makes sense and/or is possible
[21:04:25] <MateoC> that does make sense I guess
[21:04:46] <MateoC> maybe make an issue for it :P
[21:05:18] <Kryptonic> So like, I'm doing kinda what Oiram does where it has multiple recipes, on at the very top that simply makes a palette using all the images in the folder, and the all the other recipes are told to use that generated palette
[21:05:54] <MateoC> sure
[21:06:08] <MateoC> I think that convpng needs another rewrite

Add option to output defines in seperate .inc file

When exporting to appvars (I think it only fits with ASM appvars), add an option to output all the defines in a seperate .inc file, so for each image x_width and x_height, and preferable the offset too, so sprite 1 would have offset sprite0_height * sprite0_width + 2 if you get what I mean. This would help a lot if you have a game which loads the sprites from an appvar, but you don't want to manually set the sprite heights and widths, and offsets. :)

Weird extra semicolons being added to C tilesets

Using a 320x240 image and this convimg.yaml I end up with a weird behavior where convimg is adding illegal semicolons to the end of functions in the C code.

convimg.yaml:

output: appvar
  include-file: var_gfx.h
  name: var_gfx
  source-format: c
  palettes:
    - tiles_gfx
  converts:
    - tileset

palette: tiles_gfx
  images: automatic

convert: tileset
  palette: tiles_gfx
  tilesets: {tile-width:80, tile-height:80}
  compress: zx7
    - tileset.png

var_gfx.c:

#include "var_gfx.h"
#include <fileioc.h>

unsigned char *var_gfx_appvar[2] =
{
    (unsigned char*)0,
    (unsigned char*)176,
};

unsigned char *tileset_tiles_compressed[12] =
{
    (unsigned char*)0,
    (unsigned char*)307,
    (unsigned char*)1644,
    (unsigned char*)2870,
    (unsigned char*)3053,
    (unsigned char*)3840,
    (unsigned char*)4738,
    (unsigned char*)6021,
    (unsigned char*)6451,
    (unsigned char*)7029,
    (unsigned char*)8642,
    (unsigned char*)10278,
};

unsigned char var_gfx_init(void)
{
    unsigned int data, i;
    ti_var_t appvar;

    ti_CloseAll();

    appvar = ti_Open("var_gfx", "r");
    if (appvar == 0)
    {
        return 0;
    }

    data = (unsigned int)ti_GetDataPtr(appvar) - (unsigned int)var_gfx_appvar[0];
    for (i = 0; i < 2; i++)
    {
        var_gfx_appvar[i] += data;
    }

    ti_CloseAll();

    data = (unsigned int)var_gfx_appvar[1] - (unsigned int)tileset_tiles_compressed[0];
    for (i = 0; i < tileset_tiles_num; i++)
    {
        tileset_tiles_compressed[i] += data;
    }

    return 1;
}; // This right here is what I am talking about

While it can be manually corrected it is still rather annoying and I figured was worth reporting.

ConvPng seems to have badly compressed/encoded my image

So, I have been struggling with one sprite that seems to be corrupt after compression/encoding.
In earlier builds, it would crash in Cemu, with the Console suggesting "null pointer dereference".
I fixed that with difficulty, and the program no longer crashes, but the sprite renders garbage. Exiting the faulty screen corrupts the background.

Relevant Code from my Project: https://pastebin.com/j54gn3Un
Convpng.ini: https://pastebin.com/RPk2Kps4
Image in question: https://imgur.com/a/iGLWhnn
Animation Showing Error: http://clrhome.org/startrek/temp/corrupt_show.png

Crashes when converting AoCE graphics

Sorry to make this issue again, but converting AoCE graphics still crashes, either after converting the buildings or after exporting the appvars. I use your ConvPNG and my own one but both are crashing.

Suggestion to add decompressed size to output header for appvar, if #Compression used on whole appvar.

So, as you know convpng has the option to Compress individual sprites, or the entire block of sprite data in the appvar. When using the former, it would obviously be simple to use, as decompressing the appvar returns a nicely formatted array of sprites, which the _init() routine can then read. The problem is that when #Compression is used in the #appvarc group, there is no decompressed data size to help with malloc'ing a buffer for decompression. While this can be done by hand using the image sizes, convpng seems designed to set things up nicely for you, so this is something that should be included... #define the decompressed buffer size if #compression is specified in the appvarc block in convpng.ini.

#OutputDirectory doesn't work properly

When you set #OutputDirectory to something like test, which would put the .asm files in the folder test, ConvPNG does create the .asm files, but only the header in it, not the actual data, something like this:
; Converted using ConvPNG and 2 empty lines; nothing more. I've tested this with #GroupASM in case that might help.

That one weird transparent format

Um yeah that thing...

[2017-04-30 10:46:42] <Runer112> speaking of convpng
[2017-04-30 10:47:00] <Runer112> did you ever create the fast transparent sprite conversion
[2017-04-30 10:48:24] <MateoC> oops
[2017-04-30 10:48:26] <MateoC> No :P
[2017-04-30 10:48:46] <Runer112> I recently rediscovered my attempts to create that routine
[2017-04-30 10:48:52] <Runer112> I think the unclipped version is actually done
[2017-04-30 10:49:02] <Runer112> would be nice to test i
[2017-04-30 10:49:10] <MateoC> Okay :)
[2017-04-30 10:49:18] — MateoC gets out the logs to find the format
[2017-04-30 10:49:55] <Runer112> each row is just an alternating sequence
[2017-04-30 10:50:03] <Runer112> trans run length, opaque run length + data
[2017-04-30 10:50:15] <Runer112> always starts with trans
[2017-04-30 10:50:39] <Runer112> (so if the row actually starts opaque, just emit a 0 for the first trans run length)
[2017-04-30 10:50:58] <MateoC> Okay :)
[2017-04-30 10:51:05] <MateoC> Just normal rle?
[2017-04-30 10:51:16] <Runer112> not normal RLE, no
[2017-04-30 10:51:22] <Runer112> but similar
[2017-04-30 10:51:34] <MateoC> Got it
[2017-04-30 10:51:51] <Runer112> basically, the "run" has no value associated with it
[2017-04-30 10:52:00] <Runer112> it's a meta transparent run

Ability to specify a name when defining a fixed palette index

You should be able to specify a name when defining a fixed palette value, which would be added to the group header as a define for that index. This would prevent the need for magic values when using fixed palette indexes.

For example, adding #FixedIndexColor: 2, 255, 255, 255, WHITE to a group named "gfx_group" in convpng.ini would add the line #define GFX_GROUP_WHITE 2 to gfx_group.h. You could then use gfx_SetColor(GFX_GROUP_WHITE); or similar.

Palettes cannot be generated with no images

When trying to create a palette with no images, convimg gives the error [error] No images to convert for palette 'night'. It would be useful if you could generate a palette from only fixed index colors. I use this for dynamic palettes so that I don't need multiple copies of sprites in different colors, and currently, I have to include a "dummy" image to get the palette to generate.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.