Various games made by Alpha72 Games

[somerandomhefan]

Early games by this company initially store their data in a temporary container with the extention .dam. However, when running for the first time, they briefly extract the files, delete the container, then repack them into a larger .dat file, presumably to reduce load times.

This script already supports the .dam files for the PC versions of Snail Mail and The Magic Blackboard, albeit not quite perfectly. The extracted file names are in all caps. This is clearly not supposed to be the case. When temporarily extracted by the games, the file's names have both uppercase and lowercase letters. References to such file names can also be found in some of the extracted .txt files.

The .dam files of Chromentum, Chromadrome, Chromentum 2 and an early version of Chromadrome 2 are unsupported, as are all of the .dat files.


Snail Mail's Wii version has a .daw file that's already supported, though not without several issues. In addition to the aforementioned incorrectly cased file names, most of the .tga files are empty. Also, the .wav files are unreadable. Either they're extracted incorrectly or they use a nonstandard format.


The game's Android version is unsupported. Bizarrely enough, its file container has an .mp3 extension. This one should be very easy to figure out. Its data seems to be completely unobfuscated.


Later versions of Chromadrome 2 as well as Gling use yet another different format with the extension .pkg.


All file containers mentioned can be downloaded from here. Most of the files have been trimmed with the filecutter script. The only exceptions are Gling's container (smaller than 4 MB) and the one for Snail Mail's Wii version (just in case the full file is necessary to figure out what's wrong with some of the extracted files).

[aluigi]

Script 0.3.
They are various different formats but I have been able to support all of them in one script

[somerandomhefan]

Wow, that went quickly. I just tested the new script, but there are unfortunately various issues.

First of all, the .dat files are still all unsupported. I'm assuming you didn't work on them, right? I guess supporting them isn't essential since all their data is initially stored in the .dam files, but it does force people who have already run the games in question to reinstall them in order to get the .dam files back. Or did you try to support them, but made a mistake because of the trimmed files? If so, I'll upload the untrimmed versions.

Second, the issue with the all caps file names in the .dam files (safe for Chromentum 2's and Chromadrome 2's) still exists. I guess this isn't much of a deal for most circumstances, though it could prove annoying to my modding plans for Snail Mail's PC version mentioned further down below.

Third, the .wav files found in most of the .dam files are actually .ogg files, so not all media players can open them unless you correct their extension. Snail Mail is the only exception to this. Its SFX files already have the .ogg extension.

Fourth, I get the impression that the content of the "Chromacing" directory in Chromadrome 2's .dam file has been extracted incorrectly. It consists of 18 .dat files with a size of 3 MB each that seem to contain nothing but nulls. Would be a pretty bizarre design decision if that's the way they're supposed to be. Perhaps having the untrimmed file would help?

Fifth, extracting the .mp3 file of Snail Mail's Android version gave me this error:

asm (Snail Mail Android).mp3:

offset filesize filename
--------------------------------------
000087b8 16382 randtable.bin
0000c797 41678 openfeint_offline_config.xml
0000ce0c 262163 OBJECTS/FONT/FONT.PNG

Error: the compressed zlib/deflate input is wrong or incomplete (-3)
Info: algorithm 2
offset 0000ce0c
input size 0x00008301 33537
output size 0x00040013 262163
result 0xffffffff -1

Error: the uncompressed data (-1) is bigger than the allocated buffer (262163)

Last script line before the error or that produced the error:
192 clog NAME OFFSET ZSIZE SIZE

Perhaps using the filecutter script on this file was a bad idea. Here's the untrimmed version. I'd really appreciate if you could figure out this format in particular. The Android version contains some additional levels not found in the PC version, yet seems to use the exact same text-based level format, so I'd like to try importing them.

Sixth, most of the .tga files for Snail Mail's Wii version are no longer extracted at all. If you're certain that their data is nowhere to be found in the .daw file, I could look for other potential locations among the game's files.

Seventh, a lot of the .tga files in Chromadrome 2's .pkg file are unreadable. For example, "Data\Chromacing\WorldChromaA.tga" Again, in case you need it, here's the untrimmed file.

Eighth, the readable .tga files in Chromadrome 2's .pkg file as well as all the .tga files in Gling's .pkg file are vertically flipped. Perhaps it has something to do with the way the games render them, similar to how textures in the Unity engine are also vertically flipped. Is there any easy way to have QuickBMS correct them?

[aluigi]

1) dat are fully supported and I can extract the samples you provided perfectly
2) there is no issue, filenames are exactly those provided by the archive, what's the problem if the filename is HELLO.DAT or hello.dat?
3) guessing the extensions is something I don't like because mp3 can't be recognized and would be saved as .dat, anyway now there is the variable GUESS_EXTENSIONS in the script which is set to 1, set to zero to disable the auto-guessing
4) they are just the information provided by the archive, it says that these files are all the same and all at offset 0x01549491, all correct
5) fixed, these formats are totally insane
6) upload the archive
7) another madness of these formats, it contains compressed size, uncompressed size and zlib compressed data, now it's supported
8) no, the script extracts the original files without modifications

Script 0.3.1

[somerandomhefan]

1) Wow, this is embarrassing. Apparently, I had forgotten to update QuickBMS on this PC. Sorry for the confusion. The latest version can indeed extract the .dat files. Interestingly enough, it seems the reason the .dat files are significantly larger than their .dam equivalents is because during the format conversion, the images are converted from .png into some kind of uncompressed format. When extracted from the .dat files, they're falsely given the extension .dat, but IrfanView can still read them. I would assume their new format is uncompressed .tga, given that this is the extension they're supposed to have, according to the various other files referencing them. Their header is (or at least starts with) either 00 00 01 or 00 00 02. Are those .tga headers? There's also a very minor issue with an .ogg file in Chromadrome 2's first version. It's correctly extracted from the .dam file in the Music directory and named Chromadrome2.ogg. However, when extracting the .dat file, the Music directory doesn't exist and the file in question is instead located in the root directory and named 00000031.ogg. Here's the untrimmed .dat file.

2) Well, various other files in the archives refer to them in mixed case letters, but I suppose it's possible that the case information was lost when they were initially packed and the engine doesn't actually care about their case. If you're certain their filenames in the containers have only a single case, then it should be no cause for concern.

3) Thanks for fixing it. Now all sound files have the correct extension.

4) Okay then. Perhaps small sections of the files I overlooked have something other than zeros. Either way, this is probably some unimportant internal format, so it doesn't really matter.

5) Works perfectly now. Thanks a lot.

6) I already uploaded the entire .daw file in my first post. I didn't trim it because I anticipated you might need the whole thing to fix its issues. That said, I did discover some fairly large .tpl files in them. Perhaps that's where all the textures are now stored, and the empty .tga files are either meant as references, or are accidental inclusions that are no longer relevant for this version of the game. I already installed a program for converting .tpl files. Just need to reboot my PC and figure out how it works. I'll post an update later. Also, I forgot to mention it, but the .wav files are still unreadable. Maybe they're some Wii-specific sound format? I'll see if I can find any information about programs that can handle those. Also, I think you broke something in the latest script version. It now gives a lot more files the .dat extension, such as the .tpl files.

7) Unfortunately, some of the previously unreadable image files now have the same issue as mentioned in 1). Meaning they're in some readable format that starts with 00 00 01, yet have the .dat extension. It's more of an issue here because there are also lots of non-image .dat files in this container.

8) That's okay. I'll just flip them with IrfanView then.

[aluigi]

1) tga files don't have a "magic" identifier and so it's not possible to guess if some data is a tga file, I told you that I don't like to guess extensions and it's not possible to filter out tga because there are many files with tga extension in the archive but they are png or jpg.
That 00000031.ogg is a file without name, so it's saved with a sequential name and a guessed extension.

6) I don't know what you are talking about. There are no tpl files here

7) maybe they are tga, the script extracts the data as-is. the alternative is adding tga in the filtered extensions but you will get the fake tga files saved with that extension instead of the guessed one (png,jpg).

[somerandomhefan]

6) There are indeed .tpl files in the .daw container. That's the format nearly all of the game's images have. For example, take a look at the tpl directory. Everything there is in the .tpl format. I just managed to convert them both with this toolchain and BrawlBox. With this, the mystery of the game's images is solved. It's just that the latest script version now falsely gives them the .dat extension. I spotted a few files with incorrect extensions in other archives as well. I'm assuming this new issue is caused by the newly added GUESS_EXTENSIONS variable. Is it possible to make the script only guess extensions for the .wav (actually .ogg) files in the .dam and .dat containers, or does this variable always apply globally?

The .wav files in the .daw container are still a complete mystery, unfortunately. I was only able to find information on two Wii-specific audio formats (.brsar and .brstm), and Snail Mail's Wii version uses neither. I suppose we can give up on those, then.


Thanks again for your help with the Android container, BTW. I'll see if I can import its unique content into the PC version. Hopefully, the engine can load external assets.

[aluigi]

Ah ok, you meant that there are files in tpl format to which is assigned a dat extension, yeah that's the effect of the extension guesser.

I have updated the script to 0.3.2 for guessing the extension only for the "wav" files, that means all the fake tga will have the tga extension instead of png/jpg but at the same time the real tga will no longer have the dat extension.

[somerandomhefan]

Hmm, it seems it's rather difficult to get Snail Mail's PC version to accept modified assets. It's only willing to load external files as a fallback in case no .dam or .dat file is present. When I delete the .dat file and instead place all the extracted assets in the game's directory, it briefly starts loading, then crashes. I can get it to display a modified loading screen, but that's about it so far.

I would assume there's something wrong with some file it tries to load a few seconds after startup, but it's really hard to figure out which one. They all look fine at first glance. You probably don't have any idea either, do you? Just in case, here's the untrimmed .dat file.

Repacking either the .dam or .dat file with QuickBMS probably isn't a viable alternative. I need to increase the size of some files and even add new ones.

I'm fairly confident I could make the levels exclusive to the Android version playable in the PC version if I just figure out a solution to this. Both versions seem to use the exact same text-based level format. I'll keep investigating.