ROM Hack GBA3 xBPP specs

[hackotedelaplaqu]

Hi men,


I'm looking for the xBPP (aka GB3) specs.

This little info was given to me by Auryn but google translate is a disaster and besides the bits it's incomprehensible :

Source


GBA3 XBPP

引用:

解释： 2 个位代表一个点，CT2中所谓的GBA3 XBPP，其实就是双层Tile结构，并以BPP为单位从右到左进行反读
颜色： 4色
示例： 10011100，从右到左，2位为单位进行读取，结果为：00,11,01,10，第1和第3个值代表第1个 Tile的1-2个点，第2和第4个值代表第2个Tile的1-2个点
附注： 为什么要使用这种双层Tile组合在一起存储的格式呢？据CT2作者解释是因为NDS的硬件逻辑引起的，NDS 中一次性最少要读2个字节，合并存储能够提高读取效率。不过这个解释也还不太完整，具体更深入的原因留待您的发现吧。


Thanks.

 

[FAST6191]

Not a great help just yet I know but call it a placeholder or me spamming if you want.

Interesting. I saw it in Crystaltile2 but have yet to see it used in a game.

I had to go a bit further and as of figuring out a reply to this I know far more than I did and the link says it is something like the old GBA VRAM and WRAM safe LZ compression or maybe more accurately how THUMB should be a tad faster as throwing 16 bit operations down and along various buses is better. Still it does not really sit right (we it something like the undocumented BRG (as opposed to BGR) colours swap on the GBA- http://nocash.emubase.de/gbatek.htm#lcdiointerruptsandstatus scroll up) and appears to my mind to perhaps be more of a theoretical thing or more suited to a tile arrangement option than a straight up decoding method* (but hey as mentioned below we have 1bpp despite it not really existing).

Still it appears to describe a sort of combination tile arrangement similar to how you have probably seen countless 16 and 32 bit pointers in the vast majority of DS formats
(30120000 reading as 00001230 and such) aimed at grabbing small tile values at once. The explanations were not getting me anywhere so I figured I would reverse crystaltile2/build some test images and see if I could figure out the decoding.
First as the explanation said it was a 4 colour (2bpp?) image of some form by the looks of things (certainly the palette selecting options indicated as such).
Building an image then... I did this from a hex editor and got somewhere.
0000000000 0000 0100 ....
0000000004 0000 0100 ....
0000000008 0000 0100 ....
000000000C 0000 0100 ....
0000000010 0000 0100 ....
0000000014 0000 0100 ....
0000000018 0000 0100 ....
000000001C 0000 0100 ....
Decoded as a straight line down a tile albeit on the fifth pixel line (I left it as 8x8) but that is not ideal as it could just be a forced decoding of some form.

The odd part though came when I used crystaltile2 editor to make things. Feeding blank files of 0000 I then edited a cross (3 pixels left as is, 2 pixels cross, 3 more blank/original and the same vertical using the second colour of the four.

0000000000 0040 0400 .@..
0000000004 0040 0400 .@..
0000000008 0040 0400 .@..
000000000C 4444 4444 DDDD
0000000010 4444 4444 DDDD
0000000014 0040 0400 .@..
0000000018 0040 0400 .@..
000000001C 0040 0400 .@..

I then crossed the 3x3 squares with the third colour

0000000000 8040 0408 .@..
0000000004 8848 8488 .H..
0000000008 8040 0408 .@..
000000000C 4444 4444 DDDD
0000000010 4444 4444 DDDD
0000000014 8040 0408 .@..
0000000018 8848 8488 .H..
000000001C 8040 0408 .@..


Next I added the fourth colour to the upper left of each 3x3 square
0000000000 8C40 C408 .@..
0000000004 8848 8488 .H..
0000000008 8040 0408 .@..
000000000C 4444 4444 DDDD
0000000010 4444 4444 DDDD
0000000014 8C40 C408 .@..
0000000018 8848 8488 .H..
000000001C 8040 0408 .@..

Finally I got bored and filled the entire tile in with the fourth colour, all values became CC


For reference if the hex to binary converter in your head needs a bit of a tune up (numbers in hex unless obviously not)
4 binary 0100
8 binary 1000
C binary 1100

The simplistic decode has it appear as a 2bpp skip 2bits thing but looking at it, looking at the specs and fiddling with some things it does not sit right so I do not want to leave it at that but I will for now as food and films call.

I suppose I should also reverse GBA2 4BPP from CT2 as I was at it but that left me scratching my head a bit.

*had you asked about GBA/DS image decoding I would have said you have 4bpp, 8bpp, bitmap and owing to the way the filtering works 1bpp technically exists as well. 3d might have something more (it supports a measure of alpha blending/transparency) but that is getting off topic.

 

[Auryn]

I am not sure about what you did FAST, I am a but confused but anyway I solved it.
It's a 4 color font with 2 bits interleaved pixel data means 1byte = 4 pixels (2pixel in the first tile and 2 in the second).

At first I didn't think about it but we have a program that know Xbpp (CT2) so why not use it??
Let's start from first things first. Hacko it's working with a font and I took already a look a while ago and discovered that it was viewable in GBA 4bpp but the bottom part was missing. Because almost all tiles have a different size, I was thinking that the missing part was on the "garbage" I saw in that file but it seems that I was wrong. Hacko made me notice that there is like a shadow behind what we see and that is the other half of the letters. It's then that I found out that it's in Xbpp mode. In the header of that file, there is a list with the SJis value, tile width and height and naturally the offset of each tile in absolute value.
For my experimentations I tool the tile with the "O" on it that start @x12DC, the number "1" that follow it is done @ offset 134C giving us x70 bytes = 112 bytes.
Taking a look at the zero in CT2 it, we see that it's composed by 2 tikes 16x14 tiles giving us 2x16x14= 448bytes that is exactly 4 time the bytes we have from the offsets.
Now we know that probably every 2 bits i a pixel but what is the order?? And how many colors??
Here come in use CT2: I first deleted all pixels in those 2 tiles and i got 112bytes of zeros (good start).
Now just pic the first color (actually the second because the first is black) in the palette and draw a pixel in the left upper corner of the upper tile and check the hex editor (hex value changed to x01), next color same pixel (x02), next color again in the same pixel (x03) and then CT2 doesn't want to do it anymore....ok.
What if i delete the pixel in the upper tile and do the same with the lower tile?? Let's do it:
Second color in the left upper corner of the lower tile (x04), next color (x08) and again (x0C).
In hex the pattern is not yet visible but in binary, yes.

If we say that the upper tile is like this:
p00 p01 p02 p03 p04 p05 p06 ......p16
p17 p18 p19 ...................................p32
....
....
........................................................p224

The next tile follow the same order but starting from 225.

The bytes in the font in binary form:
x12DC [ p226 , p01 , p225 , p00]
x12DD [ p228 , p03 , p227 , p02]
....




I hope it's clear.

 

[hackotedelaplaqu]

Thanks Fast, thanks Auryn.
I'll need to study this but it seems clear to me.

I want to code my own codec :
1/ for the sake of knowledge and programming
2/ because I need it for custom font. Remember, VWF is made by width flag here. Editing this way directly in CT2 isn't comfortable at all.

 

[Auryn]

Thanks Fast, thanks Auryn.
I'll need to study this but it seems clear to me.

I want to code my own codec :
1/ for the sake of knowledge and programming
2/ because I need it for custom font. Remember, VWF is made by width flag here. Editing this way directly in CT2 isn't comfortable at all.

Well, I don't know how much editing you need but I believe that you will need to add the accented letters only so just edit the header and make yourself 20-30 tile pairs with the same width for the a, e, o u and some more tile pairs with a different width for i where you have the kanjis now.

 

[hackotedelaplaqu]

Well, CT2 might do the job but I whished I could send a clean png font map to my graphist.


By the way : height flag in header isn't char'sheight (wich is fixed).
Still no clue about what this value could be.

 

[Auryn]

Got it again
It's so simple that I am scared to tell you because you will spend the night slapping yourself
What I was thinking is the height of the tile, it's not because you said it's fixed but it's always....half of the width.
My conclusion is that is the number of bytes to compose the tile width or bytes/graphic line: If the tile is 16 pixels, you need 8 bytes to make the first line. If 20 pixel, you need 10 bytes and so on.

 

[hackotedelaplaqu]

Status : hacko' is slapping his face very hard......