ROM Hack Translation Hamtaro Nazo Nazo Q English Translation (problem with custom graphics)

jonko_

Member
OP
Newcomer
Joined
May 22, 2021
Messages
15
Trophies
0
Age
26
XP
131
Country
United States
Hi folks!

First time posting and I'm fairly new to rom hacking. I'm currently working on a translation of Hamtaro: Nazo Nazo Q which is (to my knowledge) one of the only Hamtaro games to never get an official English release. The first section of this post will be about the progress I've made so far and the second will detail the current challenges I'm facing.

Progress So Far
With the exception of the game icon and SDAT sound, this game seems to not use any standard DS files or conventions. Cracking open the file system, we can see this:
upload_2021-5-30_15-0-55.png

Even the things that CrystalTile2 is convinced are LZ22 archives are actually not. All of these DAT files begin with a series of pointers to items later in the file as can be seen here:

upload_2021-5-30_15-6-23.png

(That's sort of a lie -- some of the DAT files start with a pointer to the first pointer, which is always 0x08 in those files, followed by the total file length; however, they're otherwise identical.)

In some files, like MSysMsg.dat, these point to strings (encoded in a weird custom Japanese-modded ASCII) and simply encode text displayed in game (these will hereon be referred to as message files). In others, however, they're pointers to other files, essentially acting as a directory (hereon referred to as directory files). (A custom file system within the NDS file system...I don't know why anyone would do that.) I've written a quick & dirty utility to parse and edit both kinds of files (including the message files contained within the directory files). I'll include a couple of screenshots to demonstrate:

upload_2021-5-30_15-21-24.png
upload_2021-5-30_15-23-48.png
upload_2021-5-30_15-25-21.png

It's very much rough around the edges still (particularly when it comes to UX which is not my strong suit) but it accomplishes its job for the most part.

Using this utility, I'm able to change all of the strings in the game:

main_menu.png
opening_cutscene.png

Honestly, this is probably enough to release a fairly solid translation patch (given the help of a couple of translators since there are a lot of strings in the game). However, there's quite a bit of text in the game locked up in image files. Which brings us to our next section...

Current Challenges

As with everything else in this cursed ROM, the image files exist in a custom format. Because of my work with the directory files, I can at least locate which files are which with the help of a corrupter. As you can see from the screenshot of the utility above, I successfully located the main menu's "Hajimeru" (はじめる, "Start") graphic (included below for reference).
hajimeru_normal.png

Not pictured in that screenshot of the utility is the palette file, which in that directory is located after all tilesets and maps, but I have concluded that every graphic contains follows the tile/map/palette pattern. However, none of these files are in a normal format (as best I can tell) and CrystalTile2 is unable to display the tilesets no matter which settings are chosen (as far as I can tell).

Within the tile files, there are some bytes that I can edit and get sort of logical outputs; for example, here's the result of mucking around with the above Hajimeru file and carefully replacing only certain bytes with FF:

hajimeru_edited.png

However, here's what happens when I change a single "wrong" byte:

hajimeru_too_far.png

To me, this seems weird to happen while changing the bytes of a tileset (but again, I'm pretty unfamiliar with graphics files and have mainly relied on CrystalTile2 to edit stuff previously).

Things I have considered:
  • Compression. It's possible these graphics are compressed, but if they are, they're the only things on the ROM that are compressed and they're not in a standard compression format that I recognize
  • The "weird" bytes determine the length/width of the tile. Seems unlikely but it would at least explain why they completely jank up the output with such small changes.
  • ASM debugging to try to unroll what's happening. I have very little experience here and even more unfortunately, no$gba can't run this game. If people have tips on other ways to start with ASM debugging I'd greatly appreciate it.
  • Staring at these files is making me sad.
I would greatly appreciate any pointers or folks with more knowledge of how to unroll what's happening with these graphics willing to take a look here. Hope you found this post at least a little interesting and I appreciate any tips in advance!
 
Last edited by jonko_,

jonko_

Member
OP
Newcomer
Joined
May 22, 2021
Messages
15
Trophies
0
Age
26
XP
131
Country
United States
Update!

Last night, I realized that while no$gba couldn't run the game, it could run through the copyright screen...which meant there were three background textures and one foreground object I could trace in the debugger!

The files are compressed. I'm not super familiar with compression algorithms, but the opening bytes don't suggest one I'm familiar with off the top of my head. So, I followed through and recreated the ARM instructions in a very crude way in my utility and long story short:

upload_2021-5-31_16-22-23.png


It worked!!! And on the first try no, less!

The code I wrote is very literally simulating the ARM instructions, so it's extremely inefficient and causes stack overflow errors on larger files. This will be fixed when I go through and fully reverse engineer the ASM to actual C# over the next couple of days.

I have noticed that there are some objects that give it non-stack overflow errors, which possibly suggests that there's a different algorithm for foreground images (which I suspected might be the case). Thankfully, there is an animated foreground sprite in the Alpha Dream logo, so I should be able to repeat this process for that.

Still accepting advice and pointers, but I'm very excited with the progress I've made since yesterday!
 

jonko_

Member
OP
Newcomer
Joined
May 22, 2021
Messages
15
Trophies
0
Age
26
XP
131
Country
United States
Update #2

So, good news and bad news. The good news: through more ASM debugging, I was able to extract some sprites from the game. The bad news: the subroutine terminates early and I end up with only partial sprites.

upload_2021-6-2_18-33-0.png


That's the first portion of the Hajimeru sprite I was talking about in the first post. It's also the only portion I've been able to extract so far.

What's more: I looked into compression algorithms more and learned that the backgrounds I decompressed above were LZ10 compressed (so I can repackage those if I wanted to). However, I tried every one of CUE's tools on the compressed sprites, all to no avail.

If anyone is interested in taking a look, the Hajimeru sprite is on GitHub here and my simulation of the ASM subroutine can be found here. If anyone recognizes this compression format, that'd be super rad as it'd make things a lot easier than trying to debug it in an emulator that can't fully run it. :P
 
  • Like
Reactions: Vulpes-Vulpeos

jonko_

Member
OP
Newcomer
Joined
May 22, 2021
Messages
15
Trophies
0
Age
26
XP
131
Country
United States
upload_2021-6-6_17-24-18.png

I found out that there's a subroutine that runs before the decompression subroutine which loads blocks of data into memory. This means that it is block-based compression, which isn't super surprising. In any case, I was able to cut past simulating that subroutine and just guessed approximately how it must work and... huzzah!

I've asked the question of identifying this algorithm in a couple of forums now; we'll see if we get any responses. Still though, very happy with my progress so far. :)
 
  • Like
Reactions: TigerTiger

jonko_

Member
OP
Newcomer
Joined
May 22, 2021
Messages
15
Trophies
0
Age
26
XP
131
Country
United States
upload_2021-6-9_21-24-37.png


It turns out that Nazo Nazo Q is very similar to the Mario & Luigi DS games (specifically Partners In Time) that were also made by Alpha Dream! I was able to crib some code from Yoshi Magic (thanks to Salanewt and Teawater for the pointers!) and decode the animation/map data in order to reconstruct the sprites in my utility. This is super useful for identifying what sprites are what (obviously) and has already confirmed my suspicions about which files will need to be edited.

In terms of technical problems, we're in the homestretch. Only thing left is to write a compression routine, and between the Yoshi Magic decompression routine and my own I have a much better understanding of how to write one!
 
  • Like
Reactions: Vulpes-Vulpeos

jonko_

Member
OP
Newcomer
Joined
May 22, 2021
Messages
15
Trophies
0
Age
26
XP
131
Country
United States
upload_2021-6-10_8-7-33.png


I did it. (:

(I am not an artist.)

The compression routine needs to be refined as does the utility more generally, but I think I'm ready to start recruiting translators & artists. Thanks for reading!
 
  • Like
Reactions: TigerTiger
General chit-chat
Help Users
    kenenthk @ kenenthk: Uremum