ROM Hack Jump Ultimate SuperStars AAR Archive

Keshire · Sep 19, 2007

Edit: 11/18/2011

I'm no coder. I just like to crack file specs as a hobby.

File Specifications
http://jumpstars.wikispaces.com/File+Formats

FAST6191 · Sep 19, 2007

I assume it is jump ultimate stars,
for the record it ran well enough for spriting in my 6 month old of desmume (which has rudimentary sprite/tile/map viewers and such) so a current version should be fine. You also dodge the need to find palettes and decompress.

Anyhow despite hex workshop being my choice of almost always I have very little experience in defining file types with it.
Anyhow with thanks to deufeufeu:
First few bytes are ALAR (a common theme in the nitroSDK)
id

offset (normally just the two bytes unless a massive file is happening)

size (not always the same as offset difference as padding is sometimes used so as to end up word (or higher) aligned.

pad (00's but if you are dealing with a massive aar file then they may be filled with offset data)

filename ASCII, the foward slashes indicate directory. If you just want extraction then I suggest counting back 12 bytes from the name and then flip the previous 2 bytes (can be slightly confusing as an ASCII letter can appear before the name: i not J in the example below)

Followed by standard LZ, a decompression app here: http://gbadev.org/tools.php?showinfo=56

Demo section from info.aar (serves a point as some stuff is AARed twice)
CODE0000000 414C 4152 0305 0400 0000 0000 0300 0000 ALAR............
0000010 9C00 1C00 3C00 5C00 7C00 0000 0000 0047 ....

Keshire · Sep 19, 2007

QUOTE(FAST6191 @ Sep 19 2007 said:
I assume it is jump ultimate stars,
Correcto. So says the title of thread.

QUOTE(FAST6191 @ Sep 19 2007 said:

for the record it ran well enough for spriting in my 6 month old of desmume (which has rudimentary sprite/tile/map viewers and such) so a current version should be fine. You also dodge the need to find palettes and decompress.
I don't even want to attempt to sprite by hand. I find ripping file types apart more fun and rewarding.

QUOTE(FAST6191 @ Sep 19 2007 said:

Anyhow despite hex workshop being my choice of almost always I have very little experience in defining file types with it.
Anyhow with thanks to deufeufeu:
First few bytes are ALAR (a common theme in the nitroSDK)
id

offset (normally just the two bytes unless a massive file is happening)

size (not always the same as offset difference as padding is sometimes used so as to end up word (or higher) aligned.

pad (00's but if you are dealing with a massive aar file then they may be filled with offset data)

filename ASCII, the foward slashes indicate directory. If you just want extraction then I suggest counting back 12 bytes from the name and then flip the previous 2 bytes (can be slightly confusing as an ASCII letter can appear before the name: i not J in the example below)
I've so far found a lot of the ALAR header is related to the file number. This can be seen within all the /chr/*.* files. But otherwise I'm good to go with extraction. Though it looks like each file contains the picture, the bounding box, and some node data.

QUOTE(FAST6191 @ Sep 19 2007, 04:47 AM)Followed by standard LZ, a decompression app here: http://gbadev.org/tools.php?showinfo=56

Click to expand...

Luckily their tagging each data chunk. DSCP is a compressed chunk. It's fairly easily layed out. The difficulty would be figuring out their system for linking the files if one wanted to recreate them. Since their linked via the headers.

QUOTE(FAST6191 @ Sep 19 2007, 04:47 AM)

Click to expand...

(serves a point as some stuff is AARed twice)

Ya that's bothersome.

So far the chunks are fairly straight forward.

ALAR = Archive
DSTX = Some type of texture? '.dtx'
DSIG = Another type of texture? '.dig'
ALOD = Unsure. I want to assume Level of Detail, but it contains node data.
ALMT = Alignment?? '.amt' Contains bounding box and collision information.
DSCP = Compression

I DO have some experience with unknown filetypes.

http://fabletlcmod.com/wiki/doku.php

But I'm not a very good coder at all. I'm just good with providing information and hoping someone else can provide a tool for others. Otherwise I'll just use a hex editor.

Keshire · Sep 20, 2007

updated Hex Workshop Structures

The ALAR formats are differentiated into types.

Ripped Files that should be one of the characters. I can't tell if there's still compression going on in these files though. And I can't seem to get even the resemblance of a sprite.
The AAR file has been decompressed and split into:

.dtx (sprite should be in this)
.amt (bounding box and collision information)
.aod (Unsure what this is doing)

FAST6191 · Sep 20, 2007

Wow, sorry about not replying I made one up and it got lost in a sea of tabs.

QUOTE(Keshire @ Sep 19 2007 said:
QUOTE(FAST6191 @ Sep 19 2007 said:

I assume it is jump ultimate stars,
Correcto. So says the title of thread.

Sorry it said Ultimate superstars (superstars being the prequel with uncompressed GBA style graphics in pretty much RAW format within the rom as I recall).

QUOTE(Keshire @ Sep 19 2007 said:

"I don't even want to attempt to sprite by hand. I find ripping file types apart more fun and rewarding."

No argument here.

QUOTE(Keshire @ Sep 19 2007, 11:37 AM)I've so far found a lot of the ALAR header is related to the file number. This can be seen within all the /chr/*.* files. But otherwise I'm good to go with extraction. Though it looks like each file contains the picture, the bounding box, and some node data.

QUOTE(FAST6191 @ Sep 19 2007, 04:47 AM)

Click to expand...

Followed by standard LZ, a decompression app here: http://gbadev.org/tools.php?showinfo=56

Click to expand...

Luckily their tagging each data chunk. DSCP is a compressed chunk. It's fairly easily layed out. The difficulty would be figuring out their system for linking the files if one wanted to recreate them. Since their linked via the headers.

ALAR = Archive
DSTX = Some type of texture? '.dtx'
DSIG = Another type of texture? '.dig'
ALOD = Unsure. I want to assume Level of Detail, but it contains node data.
ALMT = Alignment?? '.amt' Contains bounding box and collision information.
DSCP = Compression

I DO have some experience with unknown filetypes.

http://fabletlcmod.com/wiki/doku.php

Otherwise I'll just use a hex editor.

Yeah, file reconstruction is a pain for all areas of DS hacking aside from basic NARC files. Nice to see more rom hackers though, I personally go the hex editor route and tweak an existing file or slightly redo the header in excel.

Also http://tahaxan.arcnor.com/index.php?option...id=28&Itemid=36 , http://www.pipian.com/ierukana/hacking/ds_narc.html , http://kiwi.ds.googlepages.com/nsbmd.html and http://kiwi.ds.googlepages.com/sdat.html may be of some interest. It does not have what you want (other 2d files, general archives, 3d and the sound format are detailed there) but it could prove interesting if you want to make a makefile/compiler sort of thing. http://knightsc.googlepages.com/narctool.zip has source as well although it is for a different form of DS archive.

Also I must apologise if I came of badly, most "spriters" seem to be after the end result and little more.
Anyhow back to business "collision" data aside I would suggest the rest is the palette although I seem to have misplaced my notes on the format of it
I assume you know basic 2d GBA/DS graphics ( http://gbatemp.net/index.php?showtopic=45360& should help if not), they are not bitmapped here so we can leave that.

Keshire · Sep 20, 2007

QUOTE(FAST6191 @ Sep 20 2007 said:
....

Thanks for the help.

Koma.aar
4bpp
.DTX (Tiling, I think)
.DIG (32 byte palette, rest is sprite)

Code:

struct DSTX { ÂÂÂÂchar ÂID[4]; ÂÂÂÂword ÂType; ÂÂÂÂword ÂNumberTiles; //?? ÂÂÂÂword ÂEnd; //Size?? Next Chunk?? ÂÂÂÂword Âunk; ÂÂÂÂdword ÂTiles[NumberTiles]; // (Tile Width X Tile Height X ??) ÂÂÂÂ//data };

CODEstruct DSIG
{
ÂÂÂÂchar ÂID[4];
ÂÂÂÂword ÂUnk; //Type??
ÂÂÂÂword ÂUnk;
ÂÂÂÂword ÂUnk;
ÂÂÂÂword ÂSize; //??
ÂÂÂÂ//data
};

I just need to figure out the tiling. I definately have the sprite. It just isn't tiled correctly. Then to figure out characters.

Keshire · Sep 20, 2007

Keshire · Sep 20, 2007

Getting closer.

The characters use a different type. They ditch the dtx chunk and store both the palette and the tiling in the dig. Their also compressed. I haven't found the decompress size yet. :|

And their using 4bpp linear reverse order. Or so tile molester is telling me.

edit: There should be enough information now to replace koma pictures I beleive.

Keshire · Sep 21, 2007

Win.

The second was an exact copy of the first. I just rearranged the tiles.
I'm not sure why it had 2 exactly same sprites within the file though.

Code:

struct DSIG
{
ÂÂÂÂchar ÂID[4];
ÂÂÂÂword ÂUnknown; //Possibly Type
ÂÂÂÂbyte ÂPaletteNumber; //Number of Palettes.
ÂÂÂÂbyte ÂUnknown; //Bit Depth?
ÂÂÂÂword ÂUnknown;
ÂÂÂÂword ÂSize; //Size of data after Palettes. Multiply by 4

struct ÂPalette ÂPalettes[PaletteNumber]; //Each Palette is 32 bytes
ÂÂÂÂdword ÂUncompressedSize; //This is the uncompressed size of the first section
ÂÂÂÂdword ÂSections; //I'm pretty sure each section is it's own frame of animation??
ÂÂÂÂword ÂUnknown; Â//Related to Sections.
ÂÂÂÂword ÂOffsets[(Sections*2)-1]; //1st word = Size, 2nd word = relative offset from UncompressedSize (multiplied by 4)
ÂÂÂÂ//compressed data
};

And that will get you every sprite.

Keshire · Sep 21, 2007

FAST6191 · Sep 21, 2007

Very nice work Keshire.

Keshire · Sep 21, 2007

QUOTE(FAST6191 @ Sep 21 2007 said:
Very nice work Keshire.

No problem. I'm not much of a coder. So someone else will have to write up an import/export app. If there's enough interest I'll look at a couple other files types. Such as the computer AI or Collision detection.

Keshire · Sep 24, 2007

For the life of me I can't seem to figure out how the tiling works (having no experience with tiled sprites before).

The tiling information for this is as so:

It looks like Frame Number | Unknown | Position

Code:

00 00 | F8CA | 02 00 
00 00 | E8E5 | 0A 00 
00 00 | F8EA | 06 00 
00 00 | F8FA | 05 00

I'd like to think size and pixel offset for the unknown stuff. But I have no idea. And can't seem to get usable numbers out of it. Any suggestions?

Retal · Sep 24, 2007

I've written applications to work with proprietary file formats before. And even dissected the file format myself. But I don't often feel like I have the energy to try to reverse engineer file formats, but if you can complete your findings and publish clearly what you know then I have some interest in writing the application.

EDIT: Incidentally it surprises me how good you are at this for someone who claims that they cannot code.

Keshire · Sep 24, 2007

QUOTE(Retal @ Sep 24 2007 said:
I've written applications to work with proprietary file formats before. And even dissected the file format myself. But I don't often feel like I have the energy to try to reverse engineer file formats, but if you can complete your findings and publish clearly what you know then I have some interest in writing the application.

EDIT: Incidentally it surprises me how good you are at this for someone who claims that they cannot code.

For the most part I'm done with the actual archives. I'm just trying to figure out the tiling. It's starting to become annoying.

I'll post up everything I have on the archives when I get back to work. As far as coding goes. I can tear stuff apart easily. But building new stuff I suck at, and frequently find myself wondering where to even start.

Either way if I don't figure out the tiling then I'd be stuck ripping sprites instead of editing or creating them.

Retal · Sep 24, 2007

Well ripping is still a good start for the basis of a program.

Keshire · Sep 25, 2007

Ok we'll start with the main Archive format.

.aar

It's divided into 2 types so far.
Type 3 (ChrArc.aar, Koma.aar, Item.aar, etc etc
and
Type 2 (/chr/_b_#c.aar, And aar files within Type 3)

Code:

Type 3

ÂÂÂÂchar ÂÂÂÂÂID[4]; Â Â Â Â Â Â Â // 4 bytes, ALAR
ÂÂÂÂbyte ÂType; Â Â Â Â Â Â Â //So far I've seen 2 and 3
ÂÂÂÂbyte ÂUnknown; Â Â Â Â //Some other type of ID. Most are 05.
ÂÂÂÂdword ÂÂÂÂÂNumberFiles; Â //Number of files contained in the Archive
ÂÂÂÂword ÂÂÂÂÂunk; Â Â Â Â Â Â Â Â//Always 00 so far
ÂÂÂÂdword ÂÂÂÂÂArrayCount; Â Â//Number of Items in the Index
ÂÂÂÂword ÂÂÂÂÂSizeHeader; Â //Size of the Header
ÂÂÂÂword ÂÂÂÂÂFileIndex[ArrayCount+1]; //Absolute Offset Pointers to the File Headers
ÂÂÂÂ//Pad to start of table
Â Â Â ÂFileHeaderArray[NumberFiles];
Â Â Â Â//Pad to data

File Header
ÂÂÂÂword ÂÂÂÂÂFileID;
ÂÂÂÂword ÂÂÂÂÂUnknown; Â Â //A file type??
ÂÂÂÂdword ÂÂÂÂÂStartOfFile; Â//Absolute Offset Pointer to Start of the File
ÂÂÂÂdword ÂÂÂÂÂSizeOfFile; Â //Size of the file
ÂÂÂÂword ÂÂÂÂÂUnknown; Â Â//Always the same??
ÂÂÂÂword ÂÂÂÂÂUnknown; Â Â//Always the same??
ÂÂÂÂword ÂÂÂÂÂUnknown; Â //Possibly a Size, Pointer, or Type.
ÂÂÂÂchar ÂÂÂÂÂFileName; Â Â//Null terminated string
Â Â Â Â//Pad to next entry

Code:

Type 2

ÂÂÂÂchar ÂÂÂÂÂID[4]; Â Â Â Â Â Â Â // 4 bytes, ALAR
ÂÂÂÂbyte ÂType; Â Â Â Â Â Â Â //So far I've seen 2 and 3
ÂÂÂÂbyte ÂUnknown; Â Â Â Â //Some other File Type.
ÂÂÂÂword ÂNumberFiles;
ÂÂÂÂbyte ÂID; Â Â Â Â Â Â Â Â Â//Some type of Game Character ID
ÂÂÂÂbyte ÂID; Â Â Â Â Â Â Â Â Â//Some type of Game Character ID
ÂÂÂÂbyte ÂID; Â Â Â Â Â Â Â Â Â//Some type of Game Character ID
ÂÂÂÂbyte ÂID; Â Â Â Â Â Â Â Â Â//Some type of Game Character ID
ÂÂÂÂbyte ÂID; Â Â Â Â Â Â Â Â Â//Some type of Game Character ID
ÂÂÂÂbyte ÂID; Â Â Â Â Â Â Â Â Â//Some type of Game Character ID
ÂÂÂÂbyte ÂID; Â Â Â Â Â Â Â Â Â//Some type of Game Character ID
ÂÂÂÂbyte ÂID; Â Â Â Â Â Â Â Â Â//Some type of Game Character ID
Â Â Â ÂFileHeaderArray[NumberFiles];
Â Â Â Â//Pad to data

FileHeader
ÂÂÂÂbyte ÂID; Â Â Â Â Â Â Â Â Â//Some type of Game Character ID
ÂÂÂÂbyte ÂID; Â Â Â Â Â Â Â Â Â//Some type of Game Character ID
ÂÂÂÂbyte ÂID; Â Â Â Â Â Â Â Â Â//Some type of Game Character ID
ÂÂÂÂbyte ÂID; Â Â Â Â Â Â Â Â Â//Some type of Game Character ID
ÂÂÂÂdword ÂStartofFile; Â Â //Absolute Offset Pointer to Start of File
ÂÂÂÂdword ÂSizeofFile; Â Â Â//Size of File
ÂÂÂÂbyte ÂUnknown;
ÂÂÂÂbyte ÂUnknown;
ÂÂÂÂbyte ÂUnknown;
ÂÂÂÂbyte ÂUnknown;

Each data chunk is preceded by a 32 byte string

All the files are tag based.
Each tag is proceded by 2 bytes that are unknown.
And there is padding between and within the files.

Code:

DSCP tag 

ÂÂÂÂchar ÂID[4];
ÂÂÂÂdword ÂGBA_Compression_header; //lzss compressed file

Code:

DSTX tag

ÂÂÂÂchar ÂID[4];
ÂÂÂÂbyte ÂUnknown; Â Â Â Â Â Â Â Â Â//
ÂÂÂÂbyte ÂID; Â Â Â Â Â Â Â Â Â//Some type of Game Character ID
ÂÂÂÂword ÂNumberFrames;
ÂÂÂÂword ÂSizeofChunk;
ÂÂÂÂword ÂIndex[Frames]; //Relative Offset Pointer to Tile Table. (Offset + 12 bytes from header)
Â Â Â Â//Next your looking at an array and sub-array of 6 bytes.
Â Â Â Âword Â Â Â Â Â ÂTilePiecesArray[NumberFrames];
Â Â Â Â Â Â Â Â Â Â Â Â Â Âword Â Â Â Â Â Â Â TileNumber; //Either just the Frame number, or Number of Tiles that make up the frame in the case of sprites that contain multiple frames. (ie Support Characters)
ÂÂÂÂbyte ÂXOffset; //Pixel Offset
ÂÂÂÂbyte ÂYOffset; //Pixel Offset
Â Â Â Â Â Â Â Â Â Â Â Â Â Âword Â Â Â Â Â Â Â Arrangement; Â Â//X by Y

Code:

DSIG tag

ÂÂÂÂchar Â ÂID[4];
ÂÂÂÂword Â Unknown; Â Â Â Â Â Â Â Â Â//This is probably a type. Some DSIG's have headers that end after the palette array
ÂÂÂÂbyte Â ÂNumberPalettes; Â Â Â Â //
ÂÂÂÂbyte Â ÂUnknown;
ÂÂÂÂword Â Unknown;
ÂÂÂÂword Â Size;
Â Â Â ÂPaletteArray[PaletteNumber]; Â Â Â Â//32 byte Palettes
Â Â Â Â//End of Typical Header
Â Â Â Â//Begin of MultiFrame Sprite Header
ÂÂÂÂdword ÂUnknown;
ÂÂÂÂdword ÂNumberFrames;
ÂÂÂÂword Â ÂOffsets[(NumberFrames*2)]; 
Â Â Â Â//Relative (After the palettes) Offset Pointer to Frame as well as size. Multiply the Pointer by 4 to get the Correct Offset.

Multi Frame Sprites have each frame compressed. first 4 bytes are the lzss compression header.

The other File types I haven't looked at much.

edit:
But, there's collision, Computer AI, Effects, Shots, etc etc that exist. I'd love to find out how they link the sprites to the moves and effects.

TodX · Sep 25, 2007

Hi guys. This is my first post here

.

I'm a friend of Keshire's. I've been working with him on the ALAR achive files a bit. Here's a tool I've started working on to help out with the ALAR's.

ALAR Tool

For ease of programming, I've written this tool using .Net Framework 2.0. Available here.
It is also built using visual c++ 2005 sp1 runtime libraries. Available here.

If the program does not run correctly, I suggest trying the second link first, it's usually the culprit.

The tool currently supports opening, viewing, and exporting ALAR type 2 and 3 archives. This should help those who are currently playing around with hacking the file types. Anyway, hope it helps.

Retal · Sep 26, 2007

So I don't know why he was asking for someone to code it.

Keshire · Sep 26, 2007

QUOTE(Retal @ Sep 26 2007 said:
So I don't know why he was asking for someone to code it.

Because I came here first, before Todx saw what I was doing.

Sprite-wise. We're good to go with exporting. I'm at the moment working on the .amt file. Which looks to be some type of linking file. If we want import though there's still a few unknowns here and there that need sorted out.

ROM Hack Jump Ultimate SuperStars AAR Archive

Well-Known Member

Techromancer

Well-Known Member

Well-Known Member

Techromancer

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Techromancer

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

New Member

Well-Known Member

Well-Known Member

Similar threads

Popular threads in this forum