[rafgc]

Indeed, if i choose CONFIG > SLOT 1 > DEBUG RETAIL and reset game i see some some ROM traffic, but i don't understand the syntax completely

for e.g.

0000:[01CF8600, ofs 01BFD800] \data\data.bin

0000 is nr of file, but what is first number after bracket (offset in nds file?) and second one (offset in data.bin file?)?

It would be nice if this data would be more accurate like amount of data that was read.

No$GBA debuger gives more detiled info about tiles and OAMs, like memory VRAM location, i was able to discover Objection bubble properites like tile size is 64x64, but it is composed of small 8X8 tiles , also i managed track its whereabouts in data.bin file (by searching some array of hex data from VRAM) though it looks wierd like some parts of 64x64 tiles weren't there (like 4 first  8x8 tiles). I think tiles might be  compressed partially, beacuse i wasn't able to match perfectly data from ROM AND VRAM, though when i changed data in ROM i saw changes in certain 64x64 tile but it made it also scattered in its boundaries.

In the attachment, there is a screenshot of NDS memory where one of 64x64 tile of objection bubble is present, to the right is location of this tile in data.bin. could somebody tell me if this is RLE compression or some custom encoding?



There are even graphics data in VRAM (episode nr and title in bottom right corner at begining of the case) that won't match data in ROM at all, like its encoded or smth, the only thing that comes to mind is to track somehow using debugger where in the RAM is the original data that is decoded into VRAM, but it is not that easy.

[henke37]

The game uses a strange custom file format for most fullscreen images. But a few of the images also use a tilemap. The tilemapped images include the episode titles.

You should contact me on IRC so that we can discuss more details.

[rafgc]

Hmm, thing is i didn't never user IRC at all

From analyzing the code differences i came up with following conclusion:

Values that are repeating more  than 2 times as words (2 bytes, for e.g. 88 88) are replaced with special marker/code  or whatever it is called that tells how many pairs of two bytes are repeated, those are codes from the data in ROM:

31 80 88 88 06 00 - 98d x 88h      // 31h = 49d
0A 80 88 88 10 00 - 20d x 88h      // 0Ah = 10d
11 80 88 88 1E 00 - 34d x 88h      // 11h = 17d
33 80 88 88 1E 00 - 102d x 88h      // 33h = 51d
04 80 88 88 0B 00 - 8d x 88h      // 04h = 4d
02 80 88 88 05 00 - 4d x 88h      // 02h = 2d
0A 80 88 88 0F 00 - 20d x 88h      // 0Ah = 10d
24 80 88 88 0C 00 - 62d x 88h      // 24h = 36d

02 80 BB BB 0B 00 - 4d x BBh      // 02h = 02d
04 80 BB BB 10 80 88 88 12 00 - 8d x BBh following with 32d x 88h   // 04h = 04d, 10h = 16h
0E 80 88 88 0F 00 - 28d x 88h      //    0E  = 14d
22 80 88 88 0C 00 - 68d x 88h      //    22h = 34d

As we can the first value tells how many words should be generated here, second one is unknown, but is looks like its a static vale, third and fourth value is a word value that should be generated (pair of two values), fifth one is different most cases, but its function is unknown, sisxth one is static nad maybe it's a end of the special, code. As we can see, this control code can mix few following pairs too, in that case first four bytes that define amount and value are forming the array following with unknown vale and 00 at the end.

My guess is, that is some kind of RLE (i don't know the RLE standard used in NDS) it should be possible to decompress it and insert it that way in place of some garbage graphics that exists in data.bin (which will make it available too edit in CT2 using tile composer), after changing pointer and size it should be loaded as RAW data since decoder won't find any special codes and will push it to VRAM as is. Those chice buttons are only visible in no$gba debugger in 3D label as some objects, but hte info about that obcjects provided by no$gba are not understandable for me.



As i can find graphics data in VRAM for episode nr end its tile, it is a pain in the ass to locate where the data for choice buttons used during case (language change buttons included) are, looking through VRAM viewer in Desmume doesn't revealing anything.

90% of required graphics data can be edited directly for translation purposes in CT2, except for trial choice buttons, speech balloons, language button and those screens with ep.nr and its title in bottom right corner on black background.


Another thing, is there a software that could extract files with given pointers table, i see something like pointers table at beggining of data.bin.

Are you able to debug a stuff on NDS?



added:
Following by technical info about data.bin by Auryn i found few pointer tables that were located one after another (table + its data)(European version):

Code: [Select]

NR      ADDRESS             FILES            TABLE POINTER IN ARM9.BIN (SUPPOSELY)

1.      0x0                 450              0xC2980
2.      0x1BD418            329              0xC2990
3.      0x28d93c            420              0xC29A0
4.      0x18187b8           270              0xC29B0
5.      0x1A632E0           498              0xC29d4
6.      0x1A715D4           22               0xC29E8
7.      0x1A725DC           61               0xC29FC
8.      0x1A74F24           51               0xC2A10

There is no pointer table directly after previous table + data, maybe 8 tables is all and everything after that is RAW data (you can edit it with CT2) or maybe another pointer table for that area is hidden in one of files in those 8 tables.

[henke37]

No really, do come on to IRC so that I can explain all these details. I already figured out the pointer tables you have there. It's all documented by code. It's in my file format library.

[rafgc]

Ok. some technical updates. Most progress i've done is thanks to some explanations about archives, palettes and image format in Ace Attorney that kindly was provided by Henke37.

There are more than 8 pointer tables (some are only few entries wide) i've already found, many sliced images (128 compressed tiles) are in archives with same pointer table as everywhere, which means that data.bin is just one bunch of spliced archives (pointer table followed with files, usually first file is palette for sliced images except for graphics with embedded palette).

As it is obvious that there are many uncompressed images in data.bin, which could be edited simply with CrystalTile2, there are also compressed ones we won't  have possibility to see in such a tool.
Thats where LZ77restructor2 comes to help. Just open data.bin with this tool, and it will scan through file for lz77 files, after  unchecking all optiopns in Filters table, we have access to over 5000 files in European version. Almost all images will be displayed perfectly in B&W, tht's kind of surprise, because it is rare to see proper image without palette. Thats not because this tool can magicly guess the pixel brightnes, but because Capcom arranged colors from darkest to brightest in palette in most cases. To see image properly you have to select 4bpp or 8bpp, select number of tiles in a row (usually 32 or 64) and switch the palette to 16 or 256 grayscale shades. Usually 4kB files are 4bpp and 8k ones are 8bpp. If displayed image have embedded palette, you will see some tile(s) with noise at top left corner, image will be also shifted then (evidence room video). Unfortunately, there is no option to read palette from compressed file, you have to export that file, open in Crystal Tile 2 and switch to hex editor. Most times the palette is just at beginning of the data, so by pointing first byte and clicking RMB, select DATA -> Palette, to the left, switch labels to palette and click export, select .ACT format and save, if you pointed start of the palette properly you will see proper colors after you load ACT file to LZ77 recompressor.

This is one of examples of such action:



If the image is displayed perfectly without noise tiles, than its palette is stored in file, usually it is located 512 bytes before the first part of image in archive (32 bytes for 4bpp images), in that case you can load palette from ROM, just substract 200h from address of first part of image (substract 20h if image is 4bpp), click "load from ROM", type that address and select nr of colors to read accordingly to image format (16 for 4bpp and 256 for 8bpp) like here:

Before


After:


i didn't do this yet, but, if it comes to for reinserting, this isn't as easy as editing uncompressed data because final size depends on contents of file. If compressed file will be smaller than original, then it's ok (eventually you will need to change file size in pointer table), otherwise you have to find new place for that file, it may be unused graphics file or you can place it where data.bin ends, relative address must be recalculated as well in pointer table.

There are also files compressed with RLE (2 videos) and other ones ubknown for me yet. Speech ballons are RLE compressed too. Currently i don't know a tool that could display RLE files like LZ77restructor (adding this to this tool would be nice as well as support for tiles wider than 8x8).

As for choice buttons during trial, they are LZ77 compressed and located just before uncompressed choice buttons used in exploration. Desmumes console NItroFS debugging feature helped me here, lz77restructor will find those files and show you in list after unchecking "show only divisable by 32", but you will only see garbage there because it's "tiles" (or rather a textures) are 256 pixels wide and are not supported in this tool (too bad there is no adjustment of tile size).
But if you extract this file and load into CT2 yo can see it clearly.

French Larry Butz in LZ77restructor:



French Larry Butz in CT2 after decompression:



I hope i helped somebody to make things a little clearer.

[VicVergil]

Thanks a lot about that tip with the compressed choices and buttons.
But did you figure out how the "Objection!" "Hold It!" speech bubbles are stored? That bit is causing me a fair bit of trouble.

Also, it seems editing the files for the evidence (that are found uncompressed in Data.bin) does seem to affect them only when they're in the bottom screen, but not when they're in the top screen. Maybe it's a compressed duplicate?

[henke37]

It's more like mip mapping. The game stores multiple copies of evidence, one for each size it is shown as. The smaller sizes are more difficult to find.

[rafgc]

But did you figure out how the "Objection!" "Hold It!" speech bubbles are stored?

As for speech ballons, it's more complicated because it seems to be just RLE files without header. I didn't dig deep into that, but i found Objection (i don't know if french Objection is different than English one since they are same words) palette at 024D10D8h and pointer table composed with only pointers at 024d3e50 (12 entries), whole speech balloon is divided into 12 64x64 tiles which are composed of 8x8 tiles. To edit this you propably would have to extract in hex editor RLE data, add a header and decompress with a tool that can do this, load into CT2, adjust parameters to display a tile, load palette, use tile composer tool or select all tiles and export as image, repeat it for all RLE files, splice it together, edit, divide into 64x64 tiles and save in place of exported images from CT2, import images in CT2, save, RLE compress each 64x64 tile and insert. If new file won't fit, find new place for it and edit a pointer which will reflect new position. I don't know how game engine know how many data should be read from file since there are no file size entries in pointer table, maybe it just read the data till 64x64 tile will be filled or maybe its size is somewhere in arm9.bin.

Also, it seems editing the files for the evidence (that are found uncompressed in Data.bin) does seem to affect them only when they're in the bottom screen

As for graphics, the top screen is working in 2D mode and bottom in 3D mode, everything displayed in top screen is composed of 8x8 tiles, this is tile size supported natively by NDS engine. Since bottom screen is working in 3D mode, it can use any tile size like 128x8 or 256x8 as texture. I'll give you an example with the big case name button "First Turnabout" that will scroll from bottom screen to top and then blinks before you start a chapter. At first look you would say that it's same graphics, but it isn't, top screen button is composed with 8x8 tiles and bottom one is 256x8. If you already found bottom buttons, the top ones are just before them (254ED68 - 8x8,  2562968 - 256x8  (E) rom).

EDIT: Today i changed one of choice buttons during trial, the file size was smaller than the original, so i just insertet it with lz77restructor2, it seems that NDS doesn't bother about size in pointer table. It would be good to write a notes for replaced buttons what original filesize was, so we could avoid unexpected behaviors if we'll back to change something and resulting size will be greater than original.

[henke37]

Wait, what kind of header do you want to add? What data would it contain?

Also, I am not sure about the objection bubble having what people would call a pointer table. I find it much more likely to be an OAM table. Did you actually check if this is the case?

[rafgc]

Objection data doesn't have a header that indicates compression type (0x30) and file size, i don't know if dsdecmp will decompress it like that.

First entry is at 024d3e50 and its value is 0x30, there is 12 entries, if you add 0x30 to 024d3e50,  you get 024d3e80 and thats where data of first tile begins. I don't know how OAM looks like yet (is this the tilemap?), so i
guessed that that's a pointers.


Also, i discovered today that witness testimony and cross-examination animated text is stored as RLE data without header too and it will be hard to edit that as its scattered into various size tiles (OAMs?)

[henke37]

OAM is not really a tilemap. But it does a similar job. They both control where tiles are displayed. The difference is that OAM is for objects, rectangles that can be moved around freely on the screen. A tilemap places tiles on a single grid, one of the four background layers.

[rafgc]

Thanks. I updated my info about OAMs, now i know why no$gba is showing 3 word values for OAM and there is even OAM calculator to calculate its properties.


Tip for languages that contains special letters:
Since in (E) version Objection bubble is same for both languages, i wanted to give up about translating them as creating separate object for my language is beyond my abilities (deassembling, code injection). I dodn't thought about US rom earleir because there are no special characters like in French to edit, but i tried to check something today and  i used info provided in this thread to loacate a character width table (0x000B3D08 in arm9.bin). If you go to that address you will find after few bytes  array of 0E values, this is character lenght of 15px used for japanese letters, first encountered 0E belongs to first japanese character just after roman alphabet. Use YY-CHR to edit japanese characters, then modify those 0E values accordingly to character width (character width + 2 transparent pixels). Follow this simple logic to create your own letters. If your alphabet is using letters that have something above like dots or lines, use YY-CHR shift feature (SHIFT + arrow keys) to lower each character a little (including all other ones) so you will create a space above capital letters. I lowered all characters 2 pixels down.

And this is the result, letters from my language in (U) rom:




Character width values edited in hexeditor:



There is one strange thing about character generation text by PW engine, the last character in line is always displayed as 15px wide, you can see it if you try to display japanese character after modyfing the table, this isn't a problem though as you will never see those additional pixels.

To make usage of character codes ({64, {65}. {66}.... ), use your native letters when editing the script and record macro after that. From now on, you will be able to replace your native letters to their control code equivalent simply by clicking on macro you created.

[Chesnok]

I need to extract and change graphics in PW1

Has anybody got this tool?
_http://romhacking.trd.br/projects/pw/lib
/exe/fetch.php?media=scripts:pw1:imagens_a_editar.rar

---

Or what tool you can recommend

For ideal, I want dump picture extractor. It's comfortable for translators (I'm some programmer and helper of the translation project)

[A7med]

It's not actually an editor. That file contains exported images and their offsets in the rom done by the Portuguese translation team. You can translate them with Photoshop then import them back using CrystalTile.

https://www.dropbox.com/s/hyyz6ix2xndf7q0/imagens_a_editar.rar

[Chesnok]

Thanks!

[scorp256]

Is there any offset list apart this one? https://www.assembla.com/code/sdat4as/subversion/nodes/HEAD/GS1Extracter.as

As henke37 work covers only 50% of the file at max. There is lot of other images inside there, animations, etc., but they are or unpacked or without headers, so maybe someone already digged all these information from the executable? I saw that deufeufeu have extracted them somehow, but I do not see any tools or docs for that...

[rafgc]

I think that currently translating PW is not possible properly with PWSE. I recently looked into file generated by this tool and it generates pointers improperly (didn't looked into other things), instead of 0 PWSE inserts F (maybe the mask was set wrong), i really don't know how it is possible that this script is working at all (PWSE can't convert it's own scripts back to text), but comparing original .bin file (you have to extract it from .bin with gbalss) with the one generated with PWSE, reveals clear contradiction between those two.

[onepiecefreak]

Hey there.
I'm translating Ace Attorney Trilogy for the 3DS.
Here is my thread:
http://gbatemp.net/threads/translation-ace-attorney-trilogy.444652/

I programmed a python script that can extract and create the script files from this 3DS game.
Since the engine is the same this tool also works for NDS games.

It hasn't this flaw mentioned on page 3. The main problem was that mode 0x36. It's something like a "raw" jump.
The single argument, that this command needs, is the "pagenumber" given in the index of every script file.
Example: The index consists of 100 entries. The 100th entry isn't an ordinary offset in the file it's a 32bit value starting with 0x0200. The following 16bit are the page that is loaded with this command.
So if the 32bit value is 0x02003200 the page that will be loaded is 0x0032 -> 50. So page 50 would be loaded and normally executed.

My script originally based on PWSE. In addition with my "fixes" you can use it with Ace Attorney Trilogy and the NDS games like you wanted to with PWSE.

[rafgc]

I was writing a tool in C to convert bin to txt and vice versa and i was wondering what are those 2 pointers at the end pointer table that points out of the file. I was marking those as invalid pointers and planning to pasting them back into pointer table at some point of time.

It's a bit weird, you say it should be like 0x02003200, but in USA ACE attorney first script file have 0x00540002 and 0x00700002 if you group it into DWORD, but as two separate WORDS it is as you say.