-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable conversion of image sizes that will not fit a tile #29
Comments
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. |
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. |
…y match the allowed sprite sizes (still must be divisible by 8 though).
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. |
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"... |
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. |
…ow emit minimal palette (sized 16 * number palette banks used).
Cool! 🥇0 Files look perfect now. |
See #30 for a followup. @ the auto cutting idea I had. I believe it would be better to have the behavior be explicit |
Sorry for reopening. I was trying something with animations, but mode=4 and -split did the trick for me... |
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"
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):
This should draw something resembling the image, but it doesn't. |
What did the sprite version of the image look like? |
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.
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...
The text was updated successfully, but these errors were encountered: