stag019 / rgbgfx Goto Github PK

Better error handling for libpng warnings and errors. Warnings about NULL text key entries should be suppressed (see TODO comment in get_text() in png.c).

Currently, trim has no limits placed on it at all. This could probably lead to bad things if you try to trim more tiles than exists. The practical limit for trim would be (input png's width) / 8 - 1.

This will eventually need to be removed at the program matures.

I'm sorry but I couldn't find any other way to contact you (I suck at github) I also can't get cygwin working, could you just send me the executable, I really need it :) Thanks, and sorry for posting this here.

If the input PNG is not modified (it is already the correct bit depth) then the IDAT should be directly copied over instead of being rewritten. This would allow precrushed images to maintain the same compression size.

we need an offset of 1 pixel and a width of 13

"Both SYNOPSIS and the list in DESCRIPTION need to be alphabetized. In SYNOPSIS flags without an argument all go on one line, and flags within that line are alphabetized. Flags with arguments are alphabetized line by line."

Any other issues with the manpage can be lumped together here.

So it should correctly handle the lack of an output file by simply not going to the function at all, instead of erroring that it cant open a file handle to a file without a name.

I need something to test the output tilemap file with, so I can implement it.

If possible, the option checks in main.c should be broken out into (a) separate function(s)/macro(s).

I'm not sure what to do with gb struct member data. It's currently simply a pointer to a block of memory containing all of the data. This is difficult to work with (to correctly calculate a pixel's position from the input PNG file to the output file). I'm thinking of turning it into a pointer to a list of pointers to each individual tile. This might be easier to work with, if I can figure it out right. This should also make trim and mapfile easier to implement. Also, removing transpose_tiles.

It need a lot of work. It currently only correctly handles images of the correct bit depth (whether paletted or greyscale). Conversion to the correct bit depth is complicated. See comments scattered throughout the function in the source.

It starts with the command line option -b existing or not, setting the opt member binary to true or false. Then the gb struct member depth gets 1 for true, and 2 for false. However, there are other commonly used numbers derived from this, leading myself to confusion.

For the number of colors, depth 1 gets 2, depth 2 gets 4, calculated by 2 ^ depth. Also used is this value minus one (used for indexes). Another common occurrence is depth 1 gets 2, depth 2 gets 1, calculated by 3 - depth.