Game request: [Regista][160427]Root Double -Before Crime * After Days- about arc_unpacker

[rr-]

Which release? I'm asking because I see many platforms used.

[ffleader1]

Oh sorry. Steam version

[ffleader1]

Also, why you have not released another stable version for months T.T
Build the .exe seems to be a big hustle, for me at least.

[rr-]

That's what nightly builds are for. I'm busy with other projects, too. Composing changelog can easily eat up a few hours.

[rr-]

Good news CPK and HCA are already supported, bad news CG is not. It doesn't look to be encrypted, but it's scrambled - kind of like GIM. Maybe it's headerless GIM. Will investigate later

[rr-]

Relased 0.11, thanks for the final push

[ffleader1]

:D :D
Not sure what to say... (Also, if you want to add Corona Blossom, Steam Version, in the future, then it's really similar to Karakara, just uses another encryption key AFAIK)

[rr-]

Added support for XTX images

Changes should appear in tonight's build (in roughly 12 hours): https://tmp.sakuya.pl/au/

Example unpacked graphic:

[ffleader1]

So, the xtx is the image files, not cl5? :<
Man, I felt stupid. :<

[VNGirl93]

Works mostly fine now, but there are still two issues.

The first one is that the files in sys.cpk aren't decoded. Examining them with my untrained eyes revealed nothing other than that one of the files seems to be a shader. They don't even appear to have headers of any kind. I would assume this archive is where the UI images are located. The only other possible locations would be sn.bin and the executable, both of which are even smaller.

The second one is that the two font atlases (the only two .xtx files that aren't inside a .cpk file) are decoded incorrectly. They're not totally glitched, but clearly shouldn't look like this.

[rr-]

The font files are interesting. The way arc_unpacker converts them is 100% consistent with the way the game unpacks it internally just before passing it to DirectX.

There are 3 options:

• DirectX unscrambles the texture somehow (I doubt that; the same function is called for other XTX image variants and they work fine)
• The game unscrambles the bitmap on its own, in which case it's not a part of XTX image
• CRI engine unscrambles the bitmap as part of font decoding, in which case it's not a part of XTX image

[rr-]

I found out how the fonts are encoded. It's not BGR565, it's Gray4... and the glyphs are encoded spatially like this:

       cluster 1                cluster 2
,---------------------,  ,---------------------,
|                     |  |                     |
12 12 12 12 12 12 12 12  56 56 56 56 56 56 56 56 --,
34 34 34 34 34 34 34 34  78 78 78 78 78 78 78 78   |
12 12 12 12 12 12 12 12  56 56 56 56 56 56 56 56   |
34 34 34 34 34 34 34 34  78 78 78 78 78 78 78 78   | a cluster of 4 glyphs
12 12 12 12 12 12 12 12  56 56 56 56 56 56 56 56   |
34 34 34 34 34 34 34 34  78 78 78 78 78 78 78 78   |
12 12 12 12 12 12 12 12  56 56 56 56 56 56 56 56   |
34 34 34 34 34 34 34 34  78 78 78 78 78 78 78 78 --'
                                     |     |  '| 1 byte
                                     |     '---' 2 bytes
                                     '---------' 4 bytes

Each of 1, 2, 3 and 4 symbolizes one pixel belonging to glyph 1, 2, 3 or 4.

The important part is that the image is 4 times as big as the headers report it to be, and uses 4 bits to encode a single pixel rather than 16 I originally anticipated.

I haven't detemrined the exact block size, in the above example it's 8x8 bytes but I think it's actually 32, which rules out DXT.

Whether this is part of XTX or Cri or game, I've no idea.
Would appreciate some more samples of format 2 XTX images.

[rr-]

Alright I decoded the fonts and here they are:

but I won't be including this patch upstream cause it's way too hacky (block size = 48, quadruple width...). There's no way this works outside these specific fonts.

diff --git a/src/dec/cri/xtx_image_decoder.cc b/src/dec/cri/xtx_image_decoder.cc
index ecaa6bf..d4b8f20 100644
--- a/src/dec/cri/xtx_image_decoder.cc
+++ b/src/dec/cri/xtx_image_decoder.cc
@@ -80,19 +80,39 @@ static bstr read_tex_0(const Header &header, io::BaseByteStream &input_stream)

 static bstr read_tex_1(const Header &header, io::BaseByteStream &input_stream)
 {
+    const auto block_size = 48;
+    u8 intensity_map[] = {
+        0b00000000, 0b00010001, 0b00100010, 0b00110011,
+        0b01000100, 0b01010101, 0b01100110, 0b01110111,
+        0b10001000, 0b10011001, 0b10101010, 0b10111011,
+        0b11001100, 0b11011101, 0b11101110, 0b11111111,
+    };
+
     const auto input = input_stream.read(header.aligned_canvas_size() * 2);
-    bstr output(header.canvas_size() * 2);
+    bstr output(header.aligned_canvas_size() * 4);
     for (const auto i : algo::range(header.aligned_canvas_size()))
     {
-        const auto x = get_x(i, header.aligned_width, 2);
-        const auto y = get_y(i, header.aligned_width, 2);
-        if (y >= header.height || x >= header.width)
+        const auto abs_x = get_x(i, header.aligned_width, 2);
+        const auto abs_y = get_y(i, header.aligned_width, 2);
+        if (abs_y >= header.height || abs_x >= header.width)
             continue;
+
         const auto src = i * 2;
-        const auto dst = (x + y * header.width) * 2;
-        output[dst + 1] = input[src];
-        output[dst] = input[src + 1];
+        const auto block_x = (abs_x / block_size) * block_size;
+        const auto block_y = (abs_y / block_size) * block_size;
+        const auto x = abs_x % block_size;
+        const auto y = abs_y % block_size;
+        const auto target_y = block_y + y;
+        const auto target_x1 = block_x * 4 + x;
+        const auto target_x2 = block_x * 4 + x + block_size;
+        const auto target_x3 = block_x * 4 + x + block_size * 2;
+        const auto target_x4 = block_x * 4 + x + block_size * 3;
+        output[target_x1 + target_y * header.width*4] = intensity_map[input[src] >> 4];
+        output[target_x2 + target_y * header.width*4] = intensity_map[input[src] & 0xF];
+        output[target_x3 + target_y * header.width*4] = intensity_map[input[src + 1] >> 4];
+        output[target_x4 + target_y * header.width*4] = intensity_map[input[src + 1] & 0xF];
     }
+
     return output;
 }

@@ -177,10 +197,10 @@ res::Image XtxImageDecoder::decode_impl(
     if (header.format == 1)
     {
         return res::Image(
-            header.width,
+            header.width * 4,
             header.height,
             read_tex_1(header, input_file.stream),
-            res::PixelFormat::BGR565);
+            res::PixelFormat::Gray8);
     }

     if (header.format == 2)

[rr-]

I've examined sys.cpk and it contains a few UI graphics, sound files (the ones that play in the UI) and compressed tiny bits and pieces each of which is encoded differently (= PITA). The ratio of value to effort is too low to bother.

[rr-]

The "format 2" XTX can be told from other XTX images by checking the byte
right after "xtx\x00" signature within the file. If its 0x02, it's format
2. For details please consult the decoder itself:

https://github.com/vn-tools/arc_unpacker/blob/master/src/dec/cri/xtx_image_decoder.cc#L157-L159

On Mon, Oct 10, 2016 at 1:55 AM, VNGirl93 [email protected] wrote:

Is there any easy way to identify Format 2 XTX images? Because I honestly
don't really understand what you mean. If you're talking about images that
look scrambled, the two font images are the only ones Root Double has.
If it helps, XTX is apparently a common texture format in Xbox 360 games.
Some modding communities for the occasional PC port that still uses this
format have reversed it, but their tools don't work with the XTX images in
Root Double, so it seems the format has been altered recently. That, or
it's a completely different format that just so happens to have the same
extension.

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
#54 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA_z5AUm3zLUAzUjMFji3Fgpqxa9o76Iks5qyX7agaJpZM4JYzEB
.