Aaaand, 0.8.3

Well that was fast.

Dovoto discovered some quirks in the way names were used under shared data runs and had a nice suggestion to allow images to be added via grit files as well. There was also some other small niggly bits that needed straightening out. So yeah, grit v0.8.3.

5 thoughts on “Aaaand, 0.8.3

  1. Hi there,

    I had a bit of an issue generating an 8 bit binary file with this version of grit. I can't put my finger on exactly what's wrong and I also can't find the issue from the source, but in any event... I converted a 256 color image of size 412 x 286 with both grit and PAGfx. PAGfx does have a binary output before converting to a .c file so I took that from it's bin folder to use. When adding either file to my data folder (libnds project) it's added in with bin2o per the makefile and I just just use DMA to write a portion of the image to VRAM. The binary from PAGfx works fine (it's file size is slightly smaller) but the one from grit does not. I'm not sure if maybe it's just not skipping the bmp header data or what, but anyway I figured I should let you know. I did use wingrit, so it's also possible it was an issue with that...

    Take care,
    Sylus

  2. I'd have to see more details to say what the problem could be. What exactly doesn't work in grit's case; does nothing show up at all, or are the colors messed up, or does it look like garbage?

    If I could see the original file, the outputs of both PAGfx and wingrit and the flags used in wingrit (the summary in the dialog or the header produced should be enough), I can track down what's causing this.

  3. Sorry about that, I should know better than to post an issue like this without more detail.

    I ran a couple more tests and I'm pretty sure it was because the image width was odd. What I posted before was in error, the width of the file that didn't end up working was actually 410 by 286 (all measurements in pixels). The bin output of the 412 width file from grit was the same size as the 410 width file, which appears to mean that grit is reading in the padding from the bmp file for widths that are not multiples of 4. Here's a link to a zip with some screenshots, the bmp file (it's a collision map) and the two bin outputs.

    http://72.34.42.221/~sylus101/gritissue.zip

    I know it's not typical to use images of this size. I ended up having some issues with it in code anyway and moved it up to 412 in width. So either program would have worked in the end.

  4. Oh, and what appeared on screen when the data was written to background memory looked basically skewed, which would make sense now if there was extra data in the binary.

  5. Yeah, grit-exported data will be 4-byte aligned. This is done because then every scanline starts at a word boundary, and copying in word chunks is generally considerably faster than halfword copies. Aligning data to convenient boundaries is done quite often (see BMP and PCX specs, for example, as well as texture size). The distance between scanlines (in bytes) is often referred to as “pitch”, which is usually related, but not quite a multiple of, the width in pixels. A general conversion formula would be something like this:

    // Align to a certain bit boundary. Returns pitch in bytes.
    uint align(uint width, uint bpp, uint bitbound)
    {
        return (width*bpp+bitbound-1)/bitbound*8;
    }

    Oh, and yes, if you mess on the width/pitch in copying images, you will get a skewed image as the result.

    Also, if you even have any other problems with images (garbled graphics, skews, bad positioning), go back to simply geometric objects for a while. Debugging is a lot easier if you're only dealing with straight lines and solid rectangles. In this case, for example, using a rectangle marking the border of the image would have immediately shown a gap between the right boundary of one scanline and the left boundary of the next, indicating padding pixels between scanlines.

Leave a Reply

Your email address will not be published. Required fields are marked *