Trying to see the value in GBA2 4BPP mode

Discussion in 'NDS - ROM Hacking and Translations' started by FAST6191, Jun 12, 2012.

  1. FAST6191

    FAST6191 Techromancer

    pip Reporter
    Nov 21, 2005
    Again writing the new version of the docs I am going through and getting as much hardware/format concept level stuff as I can. So after getting GBA3 XBPP straight in my head I puzzled out the GBA2 4BPP format (or at least I think I did and if I am wrong it has the possibility of changing everything) by staring at crystaltile2 tile and hex windows at the same time for a while. Judging by the fairly limited support CT2 has for it (or at least the lack of it willing to work the format as hard as it could) I am quite prepared to be completely off target.

    End result- I am now wondering why would anybody bother with it. The best I can come up with is it might compress slightly better (thinking filters rather than anything else) and that comes at the cost of being seriously limited compared to regular 4bpp, possibly a brightness command but that is a palette job or maybe it has a weird alpha channel thing going on. I can not see it being of any real use to the more exotic modes either.

    For those unaware Crystaltile2 has a format known as GBA2 4BPP that is a 4 bit per pixel format although unlike most GBA sub byte formats it is not flipped pixel to nibble as far as I can see.

    The basic idea seems to be first pixel and second pixel each has a 4 colour arrangement however the fours colours are spread over the full 16 values in a 4 bit system.

    0-3, 4-7, 8-B and C-F is the range/selection for the four values which I am numbering 0 through 3

    The first pixel selects one of the first pixels in the palette based on the range and although it makes a difference to the second pixel the first pixel is the same regardless of where it falls in one of those ranges.
    The second pixel is one of four pixels as well but the selection window of those is chosen again by the range but the value of the first pixel determines which of the four pixels it can choose from.
    Abstracting the first pixel selection to range and selection
    range 0 selection 0 (in practice this would be 0)
    range 0 selection 2 (in practice this would be 2)
    range 3 selection 1 (in practice this would be D)

    Range 0 selection 0 would mean colours 0 through 3 available on the palette for the second pixel
    Range 0 selection 2 would mean colours 8 through B available on the palette for the second pixel
    Range 3 selection 1 would mean colours 4 through 7 available on the palette for the second pixel

    As the second pixel colours are again selected by being in a range of values this is where the alpha would come in if it exists (4C is the same as 4D which is the same as 4E which is the same as 4F in CT2). This is also the final bit I should puzzle out. Certainly 4 options for alpha are better than some options available (most things are a simple 1 bit flag saying do alpha blending).