I've been looking at some graphic formats found in Kirby Squeak Squad, which were partially supported in Tahaxan, being files with the magic stamps BCLA, BCGA, BCEA or BRCA. They are simply raw data files with a custom header at the top.
The significant thing though, was that I figured out *most* of the data format for the other Sprite Sheet Type I mentioned in my earlier posts. Basically the format is very similar to the one I've worked out, it's just differs slightly in some aspects, such as lacking any header areas, or a Name Label section at the end of the file.
There's still a few things I have to figure out first, but the above picy is of a BCEA file (Sprite Sheet) that follows this other format, some kind of rock dude from the Kirby game. I haven't looked at the BRCA format yet, but all the other ones have been added.
[edit]
Just a quick thing...I finally figured out how sprite sheets store palette information. The picy below shows a single sprite using 3 different 16 color palettes for individual cells (aka, kirby, the cloud, the cake).
I've also got to figure out a what a few of the unknown bytes do as for instance going through the file above, about 15 out of 133 sprites aren't positioning the cells properly, so there must be something different about them I am yet to find out...
[edit 2]
I have been adding a few more file formats, though I also spent I bit of time cleaning up my file accessing code, which I had found out didn't do all of what I expected it to do -_- This also included some speed enhancements with scanning files to detect their format.
The latest thing I've been working on is adding support for NDS sound files...starting with the very common SDAT format, which is actually more of an archive than an actual sound file. From what I understand there are 8 sub sections in these files, 5 of which represent actual files, while the other 3 contain data for combining these files etc. So what I've done is group each type of data in sub folders, using a fake file object to reference to non-sub file data that is found in the SDAT. I've tested it against a couple of SDAT files from different games, and it isn't too bad...except some files for whatever reason reference to nowhere etc. Once I fix up the pile of bugs in my code on this, I'll start working on the actual sound file formats (SSEQ, SSAR, STRM, SWAR, SBNK), which are contained inside SDAT files
[edit 3]
Wells I've just spent the last half of a day learning all about MIDI files...why? Because SSEQ files are a custom type of them. I thought it would be wiser learning how these little suckers work before trying to write some code to decode SSEQ files on the fly, but man...MIDI files are really quite complex!! But actually once you understand them, they're a lot easier to understand than some of the much more simpler file formats. That being said, the next thing on my list of to do things is obviously write a SSEQ decoder now
Also Java has (wells I think) a much nicer MIDI sound library than the default one Windows. What would be nice though, is to learn where in the NDS file, it actually stores the sounds/algorithms for playing back sequences. I'm assuming it'd be some kind of generic file/data maybe even stored in the BIOS? Another thought was that they might be in the Utility.bin file, but that isn't always present in some NDS games so I dunno :/
[edit 4]
Okay it would appear the SBNK files may contain the sounds/instruments needed by the SSEQ files (Seems kind of obvious when you think about it), though there is very little documentation on them, so it might take a while to learn how they work. I haven't had a lot of success in porting SSEQ2MIDI to Java, simply because of the excessive amount of data these files contain, but I'll get there.
[edit 5]
Okay I've been adding all of the sound formats today. I found Kiwi.DS's SDAT documentation and it helped get a better understanding of it all
However, Java has a somewhat limited Native Sound support, and it can only manipulate data in PCM format. Apparently it can play all sorts of different data formats but it only seems to do if said formats are in their proper file format, where as I'm trying to read stuff on the fly.
From what I understand, NDS sound files come in three types. PCM 8-Bit, PCM 16-Bit and IMA ADPCM. I can play the first two types directly out of the file without having to converting anything. Unfortunately the most common one is the last one (ADPCM), since it has better compression than the other two (from what I've researched). Now I don't have a lot of documentation on it, and I doubt it will be simple to covert it to PCM.
With luck there'll be a nice Java add-on I can use rather than the limited default package (as was with OpenGL), otherwise I'll have to learn about ADPCM >_<
Oh and the reason why I'm posting this, is because I have spent the last couple of hours listening to horrible static every time I try playing a STRM file, and I finally came across one in PCM 8-Bit format. By coincidence it was the Title Screen music for Kingdom Hearts 358/2 Days, and it sounded so wonderful to my ears!!! (Well what with all that static, anything was better lol)
[edit 6]
I've been having a go a writing a ADPCM decoder...and I've had a bit of success. Playback has gone from horrible static to clearly understanding but still fuzzy :p I've been using this
site as a reference (it's actually quite hard to find solid documentation on ADPCM!!)
The real pain is that Java only works with signed variables so I've got to add extra code to translate stuff.
Here's a basic breakdown of my code...
outputBuffer.size(buffer.size * 4);
stepIndex = 0;
predictor = 0;
step = stepTable[stepIndex];
for (i=0; i<buffer.size; i++) {
for (j=0; j<2; j++) {
nibble = (buffer[i] >> (4*j)) & 0xFF;
stepIndex += indexTable[nibble];
if (stepIndex < 0) {
stepIndex = 0;
}
if (stepIndex > 88) {
stepIndex = 88;
}
signedNibble = nibble;
if (signedNibble > 7) {
signeNibble -= 16;
}
diff = (2 * signedNibble + 1) * step / 8;
predictor += diff;
if (predictor > 0x7FFF) {
predictor = 0x7FFF;
}
if (predictor < -0x8000) {
predictor = -0x8000;
}
step = stepTable[stepIndex];
outputBuffer[pos++] = predictor & 0xFF;
outputBuffer[pos++] = (predictor >> 8) & 0xFF;
}
}I've been playing around with the variables a bit *hoping* I'd strike gold and it would just be perfect...but no....Swapping between lower and upper nibble first doesn't do nothing, changing the nibble shift to 5 seems to make the sample smoother but more muffled. I figure that there either if something wrong in my code (bare in mind this was ported to Java by me), or there's some Nintendo proprietary thing going on in there. Btw if it wasn't obvious, the reference table I used are the same ones I found on the website.
Luckily I've been doing some digging and game across VGMStream, which apparently has support for most Nintendo DS audio formats, so I'll check their source code and hopefully that will sort out my problem. But if anyone is an A class expert on audio decoding, be my guest
[edit 7]
Still not much luck for ADPCM sound
I've compared my code to various implementations of it and even found out that
GBATek has some info about it also.
I'm still getting a heck of a lot of noise and/or jumpy playback.
I have however ascertained that the data is stored in blocks (size is specified in the file header), and that the number of samples in each block indicates 4 "unused" bytes as such means that at the start of every block it updates the 3 variables with the first 4 bytes of data.
Heck for all I know it could be simply Java and how it handles data (unsigned/signed, etc), I don't have enough understanding of sound playback to know myself >_<
Romhacking.net
Author