HomeForumsWhat's newResources 
 
 
Magic Knight Rayearth, we can't edit some images
Ryo Suzuki - Dec 13, 2009
  Ryo Suzuki Dec 13, 2009
After the Panzer Dragoon Saga translation to spanish we choose this RPG to make another one.





All the things seems go all right, I mean we have the full script translated, the ingame font hacked and all ready to make the insertion and then the patch.


But we have the last problem, is the diary of the 3 girls starring the game. As you maybe know this diary are images with an style like handwriting. Very cool, but very hard to modify


Some examples:








The images are somehow encoded or compressed and we can't edit it in the normal way. We found a japanese utilty named ENIKKIAT.EXE that allows to open and view the images in DOS mode.


But still we can't export it or regenerate again the edited ones.... Then we can't complete the translation....


I atach some files of the diary, seems to there is some images in each files, like a some container file, I suppose.


Atach the japanese utility too... maybe can help in any way...


http://rapidshare.com/files/320381330/DIARY.rar...


Thanks guys, you helped so much with the font of Panzer Dragoon Saga I hope you can done it again.


THANKS in advanced!

 CyberWarriorX Dec 14, 2009
It doesn't look like anything common from what I can tell. By the way, do you have a save game or save state(preferably from yabause) for the game? Maybe I can take a quick look to see what I can work out.

 Ryo Suzuki Dec 14, 2009
Sure, no problem.


There is both (save and savestate from Yabause):


http://rapidshare.com/files/320888057/yabause-0.9....


Thanks for help, mate


P.D: A friend from another spanish translation forum tell us this:


"Each file seems to be a package like a container with a lot of images.


For example enikki00.bin have:


- 4 bytes setting 6 imáges: 0x00000006

- 6 sizes of the images: 0x5748, 0x36C8, 0x3648, 0x6354, 0x6A7C, 0x6A94

- 0x5748 bytes of the image 1

- 0x36C8 bytes of the image 2

- 0x3648 bytes of the image 3

- 0x6354 bytes of the image 4

- 0x6A7C bytes of the image 5

- 0x6A94 bytes of the image 6"


Maybe this info can help too...

 CyberWarriorX Dec 14, 2009
Alright, I'll have to look to see what I can find.


  
	
	

		
		

			"Each file seems to be a package like a container with a lot of images.



For example enikki00.bin have:



- 4 bytes setting 6 imges: 0x00000006



- 6 sizes of the images: 0x5748, 0x36C8, 0x3648, 0x6354, 0x6A7C, 0x6A94



- 0x5748 bytes of the image 1



- 0x36C8 bytes of the image  2



- 0x3648 bytes of the image 3



- 0x6354 bytes of the image 4



- 0x6A7C bytes of the image  5



- 0x6A94 bytes of the image  6"


Yeah, I noticed that too. It also looks like each image chunk contains the same sequence of bytes: 0xFF 0xFF 0x00 0x01 0x01 0x00...

Actually, I noticed two other things. At the start of each of the image chunks is 0x0140 and 0x00E0. Or 320 and 224 in decimal which is probably the resolution of the image. And a few bytes later is 0x0011800(320 * 224, so probably the decompressed size of the image in bytes).

 CyberWarriorX Dec 14, 2009
Ok, so I've found the decompression scheme. Here's some pseudo-c code that illustrates how it basically works:

cmp_flg_ctr = 16;

for (;

{

if (cmp_flg_ctr == 16)
{
cmp_flg = read_next_word(); // reads 2 bytes from cmp_buf+cmp_buf_pos, increments cmp_buf_pos by 2

cmp_flg_ctr = 0;

}

cmp_flg_ctr ++;

data = read_next_word();



if (cmp_flg & 0x8000)

{
write_next_output_word(data); // write 2 bytes to out_buf+out_buf_pos, increments out_buf_pos by 2

}

else

{
if (data == 0)
break; // we're all done

// figure out the offset and number of bytes we want to copy over

offset = out_buf_pos+(int)((data >> 5) & 0x7FE) - 0x800

num = (data & 0x3F) + 1;

for (i = 0; i < num; i++)

{
data = read_word(out_buf, offset);

write_next_output_word(data);

}

data = 0;

}

cmp_flg <<= 1;

}

Here's the original assembly code(in case there's an error in my pseudo code):

decmp_start:
mov.l neg_offset, r6

mov.l cmp_num, r7

main_loop:
rotr r7

bf pass_fetch

mov.w @r5+, r3

shll16 r3

pass_fetch:
shll r3

bf/s decmp_run

mov.w @r5+, r0

mov.w r0, @r4

bra main_loop

add #2, r4

neg_offset: .data.l h'FFFFF800

cmp_num: .data.l h'10001

decmp_run:
cmp/eq #0, r0

bt/s alldone

mov r0, r1

and #h'3F, r0

sub r0, r1

add #1, r0

shlr r1

shlr r1

shlr r1

shlr r1

shlr r1

or r6, r1

add r4, r1

cpy_bytes:
mov.w @r1+, r2

dt r0

mov.w r2, @r4

bf/s cpy_bytes

add #2, r4

bra main_loop

nop

alldone:
rts

mov r4, r0

Some additional things to note. The first 4 bytes of the file(which appears to be the number of image chunks) is completely ignored and it instead Just uses a fixed offset of 0x1C as the starting point for the first image chunk.

After the image chunk is fully decompressed, you'll be left with a 16 byte header, then a 512 byte palette, and then it's the actual image data.

The header is laid out as follows:

bytes 0-3: Not sure, probably the bytes per pixel along with some other data. Palette size?

bytes 4-5: Image Width

bytes 6-7: Image Height

bytes 8-11: Offset to Image Data

bytes 12-15: Size of Image Data in bytes

 Ryo Suzuki Dec 15, 2009
Hey! pretty interesting. Many thanks!!


I think I am a bit missing at all but I think maybe some of our friends can use this valuable info to make it works...


Thnks, you're great!

 Ryo Suzuki Jan 21, 2010
Hi again guys!

Finally our friend CUE make a custom util for us to compress/decompress.

You can view it and download -includes source code- here:

http://www.segasaturno.com/portal/viewtopic.php?f=...

THANKS!!