Enable conversion of image sizes that will not fit a tile

[HorstBaerbel]

Thanks for the great tool. I would love to use it more as it seems to be the only actively developed GBA image converter, but: When I have data for sprites/objects bigger than 64x64 I find it very convenient to leave the bitmap data for them in one piece. I simply convert the image to .c and let my routine sort it out when loading the data into individual tiles at runtime. This is not possible with nin10kit. All tile data that does not have a proper size gives an error.

nin10kit --mode=sprites --bpp=4 --transparent=0 ../../data/image_192x64_16 image_192x64_16.png I[00:27:57.661]Exporting to ../../data/image_192x64_16 symbol base name is image_192x64_16 I[00:27:57.661]Reading image image_192x64_16.png I[00:27:57.669]Using GBA exporter mode SPRITES F[00:27:57.669]Invalid sprite size for image image_192x64_16, (192 64) Please fix

I'd prefer a warning (or a "--force" flag), because I know what I'm doing. As a workaround I tried converting my data in bitmap mode using "-mode=4 -bpp=4", but nin10kit was smart and converted the color data to 256 colors, not 16 colors. So no cigar. If that would work, that would be fine with me...

[TricksterGuy]

I believe I would be open to doing that. And should be an easy implementation, given that this would be used with the default 1D mapping mode.

But I will also consider having the program be a bit smarter here and to cut up sprites that are larger than 64x64 / pad to the nearest correct size if needed, and emit multiple defines for each piece so that one wouldn't have to cut up their original image just to export it..

Sound good?

And yeah I wrote this just for fun, since back in 2010 I didn't want to explain grit's command line interface to students (and the gui based ones were also a little steep learning curve). My one gripe with them all is that they don't do any error checking so that leads students in hours long debugging sessions when the exporter just did whatever.

[HorstBaerbel]

Great! Exactly, I use it with 1D mapping. This way you can basically dump a whole 16/256-color frame(tile)buffer or memory into memory. Maybe cutting up an image and exporting multiple tiles to the same file would be handy too! Good idea. An "--autotile" switch would be good for that (could become complicated though...).

[TricksterGuy]

Thanks for waiting. This should be handled by the above commit. But just to verify that this is what you wanted.

See image and exported. It will essentially treat it as if it were a valid sized sprite and dump the data as a 1D tile array. Wrote a dumb little test program to test out reshuffling that data for multiple sprites works.

The only other thing that --force won't allow (aside from doing this with 2D mapping) is if you send in an image whose dimensions aren't divisible by 8.

[HorstBaerbel]

Thanks! It works. One bug I noticed though is that a 256-color-palette is exported. I'd expect only 16 entries with "-bpp=4"...

[TricksterGuy]

Yeah that's the current behavior of --bpp=4. It's currently hardcoded to spit out the information for all palette banks formed during conversion.

[HorstBaerbel]

Cool! :1st_place_medal:0 Files look perfect now.

[TricksterGuy]

See #30 for a followup.

@ the auto cutting idea I had. I believe it would be better to have the behavior be explicit

[HorstBaerbel]

Sorry for reopening. I was trying something with animations, but mode=4 and -split did the trick for me...

[HorstBaerbel]

When actually testing it in my GBA application, I'm having trouble making it work. I have an image with 48x64 pixels and 16 colors (can't attach so linked here). I run that through nin10kit with "nin10kit --mode=sprites --bpp=4 --force --transparent=0 test_48 test_48.png" Nin10kit tells me:

I[22:05:37.396]Exporting to test_48 symbol base name is test_48 I[22:05:37.396]Reading image test_48.png I[22:05:37.412]Using GBA exporter mode SPRITES W[22:05:37.412]Invalid sprite size for image test_48, (48 64). Note that only a tile-id offset will be emitted. I[22:05:37.415]Export complete now writing files I[22:05:37.426]File exported successfully as test_48.c and test_48.h"

The .h and .c files are created and look ok (here and here). Now I try to display the image in my GBA application. It was garbled as a sprite, so I figured I'd just dump the data to the screen in Mode 4 (256 colors):

uint16_t *dest16 = VIDEO_MEM;
const uint8_t *src8 = BITMAP_DATA;
for (uint32_t y = 0; y < 64; ++y) {
    for (uint32_t x = 0; x < 24; ++x) {
        uint16_t c = src8[x];
        dest16[x] = ((c & 0xF0) << 4) | (c & 0x0F);
    }
    dest16 += 120;
    src8 += 24;
}

This should draw something resembling the image, but it doesn't.

[TricksterGuy]

What did the sprite version of the image look like?