rgbds
rgbds copied to clipboard
gbdev
Feature request: More flexible "reverse mode" in rgbgfx
I'd like to remove bpp2png.c from our projects and recommend rgbgfx -r, but bpp2png has two conveniences:
- It can guess a width based on the 2bpp size, or default to 128px, so you don't have to specify one.
- It can pad an image with blank tiles if the specified width doesn't perfectly divide it, which is not uncommon for images that have had some trailing tiles removed with
rgbgfx -x(or gfx.c's--trim-whitespace).
(I also think it's more intuitive to not have to specify -o as the input file, but it arguably makes sense for rgbgfx since -t, -a, and -p all become inputs instead of outputs too.)
I also think it's more intuitive to not have to specify -o as the input file
The main rationale behind this was that you could simply add -r to a command to reverse it.
Doesn't -x already add blank tiles to the end of the input? If not, maybe that should be added.
As for guessing the input size, unless the image is perfectly square, the guess is at best 50/50. A default width is not appropriate in general, only for a single project. (And even then, you can just specify the flag instead. No?)
-x has to specify how many tiles to pad, which you may not know offhand; -r N could just add however many tiles are necessary to make a rectangular image.
Regarding a default width, it could just use "any PNG width that can be re-generated the same way". For example, if you have 4x6-tile PNG and convert it to 2BPP, and you reverse-generate a PNG with "-r auto", it could end up as 4x6, 6x4, 12x2, 1x24, etc; any of those would be accurate to the original data.
Yes, but my point is that if you specified -x as input, you can also specify the same in "reverse mode".
Those wouldn't be accurate to the original data, since they wouldn't even be the same width.
The use case is for when you have a .2bpp from somewhere, and want to view it as a png, without having to check its filesize, divide by 16, and calculate a valid width. (Or use the always-valid but hard-to-view -r 1.) The result is accurate in that it can get the exact same .2bpp back, so for example, you can take a project full of .2bpp files and replace them all with .pngs without breaking the build.
Then the best guess to take is 1, which is equivalent to -r 1. Is it not sufficient to view the file, press up in the terminal, change the argument to -r, and pick something else?
The first half of this was implemented: -r 0 picks a reasonable width for the reversed image.
@ISSOtm A suggestion for the second half: -r 8 -x 0 would set -x to whatever value is needed to make -r 8 work.
I don't like that idea, because -x 0 is a valid RGBGFX input.
How about: if there aren't a multiple of 8 tiles and no tilemap is specified and -x is not already specified, the error messages also prints help: To proceed anyway with some blank tiles, try passing `-x 4`.