<- 1  -   of 75 ->
^^
vv
List results:
Search options:
Use \ before commas in usernames
Edit history:
Aruki: 2014-09-18 05:40:30 pm
The vertex declaration is on the material.

The stuff in there is typically floats/occasionally a couple u16s, and often the entire thing is zeroed out.
I find this entirely unnecessary:


Seriously what the hell retro?
PWE now supports every single texture format! Yay for that. All ten formats can be displayed in the viewer/exported out to DDS.

Trying to work on objects next. I made an instance view widget that displays every object loaded in the scene, organized by layer, which is pretty neat. Hopefully going to be adding more features for viewing/maybe even finally actually editing objects soon.

Speaking of which some of the object names in this game are.. really weird. A small sample:

Quote:
PlayerActor-1stcamera-Thardus_Point_the_gun_up_in_yo_samus
ActorKeyFrame floatupAnd you'r_rock_floatup
Waypoint-asdfas
Sound - Rumblestiltskin
Parasite-component-component CURLY
Parasite-component-component MOE
Parasite-component-component LARRY
Actor ScanThingy

From the ending:

Sound - RidleySaysHi
Trigger - Start this Beatch
camera3-back view of samus leaping off of cliff
camera4-front view-jesus christ
camera6-samus falling into camera-jesus christ
PlayerActor-samus running just like the devil
camera7- Enjoy the Fireworks
red chamber dream
hahaha those are great
Anywhere, everywhere
It's good to know that this game was blessed in the name of the lord.
Metroid Prime is FULL of stuff like that xD
red chamber dream
it HAS to be a texas thing
Edit history:
BioSpark: 2014-09-24 03:46:59 am
i would probably call it jesus christ too, since that's the pose she makes when jumping for the ship. much less boring than "samus arms out" or something.
it's probably more just "holy shit she's jumping off a cliff and artifact temple is exploding! jesus christ!"
Love the Three Stooges reference.
I always figured it was referring to the pose personally.
i thought it was more referring to a sort of hero shot of samus, a la jesus christ.
I cracked the HINT format from Metroid Prime 1, though there is something rather silly:
Code:
#include <common-types.bt>
struct HINTEntry
{
    string name;
    float2 unkFloats;
    uint STRGId <format = hex>;
    uint unk5;
    uint unk6;
    uint MLVLId <format = hex>;
    uint MREAId <format = hex>;
    uint roomNumber; // In MLVL (holy redundant references batman)
    uint STRGId2 <format = hex>;
};

struct HINTTemplate
{
    uint magic; // 0x0BADBAD
    uint version;
    uint count;
    HINTEntry entries[count] <optimize = false>;
}file;


The roomNumber field always matches the MREA referenced by the MREA ID in all the entries I checked >.>
Edit history:
Aruki: 2014-09-25 09:07:38 am
Aruki: 2014-09-25 09:05:53 am
Aruki: 2014-09-25 09:05:45 am
Aruki: 2014-09-25 09:04:18 am
I remember looking at that format a while ago and figuring out most of it... the only thing I have to add to that is IIRC I determined the second float was the amount of time it takes for the hint to appear, in seconds.

also obvious but the first STRG is the popup text that appears on the HUD and the second one is the text that displays on the map screen.

edit: also, the prime 2 format is exactly the same.
I would imagine prime 3 being the same as well, assetID length excluded.
Prime 3 seems to have a version number of 3 so I guess it's different? Haven't looked at the format so I have no idea how though.
I'll take a look real fast.
Eh, looks like Retro decided they didn't need nearly as much metadata:
Code:
//--------------------------------------
//--- 010 Editor v5.0 Binary Template
//
// File:
// Author:
// Revision:
// Purpose:
//--------------------------------------

#include <common-types.bt>
BigEndian();
struct HINTEntry
{
    string name;
    float unkFloat;
    float fadeInTime;
    if (file.version == 3)
        uint64 STRGId <format = hex>;
    else
        uint STRGId <format = hex>;
    uint unk5;
    uint unk6;
    if (file.version != 3)
    {
        uint MLVLId;
        uint MREAId;
        uint roomNumber; // In MLVL (holy redundant references batman)
        uint STRGId2 <format = hex>;
    }
};

struct HINTTemplate
{
    uint magic <format = hex>; // 0x0BADBAD
    uint version;
    uint count;
    HINTEntry entries[count] <optimize = false>;
}file;
red chamber dream
i heard the term "jesus christ pose" a couple times on a podcast today in reference to the "arms out" pose in other games, so i think it's a pretty common industry term and maybe in general too.
that's probably it then.
Edit history:
Aruki: 2014-10-05 12:27:32 am
Aruki: 2014-10-04 10:12:59 pm
Aruki: 2014-10-04 10:12:32 pm
Aruki: 2014-10-04 09:53:03 pm
Aruki: 2014-10-04 09:29:15 pm
Aruki: 2014-10-04 09:21:28 pm
Aruki: 2014-10-04 09:21:19 pm
Aruki: 2014-10-04 09:18:49 pm
Aruki: 2014-10-04 06:50:37 pm
I just cracked the toughest format in all of Echoes.

Code:
struct STLC {
  u32 sound_name_count;
  std::vector<std::string> sound_name_table;
};


On a serious note I actually finally took the time to learn how sound formats work and actually successfully wrote an ADPCM decoder, and was able to correctly decode music/sounds from DSPs and CSMPs without using dspadpcm. Yay! So with that new knowledge I'm having another look at AGSC. Judging by what I've seen so far I'm pretty sure I'll be able to rip sounds from Echoes's AGSCs at least (Prime's AGSC format is different so not sure about that one). Might end up releasing a tool for general-purpose sound decoding from various Prime games audio formats that doesn't rely on dspadpcm if I'm successful.

EDIT: Sound effect dumping from Echoes AGSCs completely works now - just successfully dumped all the sound effects from Echoes's FrontEnd and Weapons AGSCs, and no reason to believe the others won't work as well!

EDIT 2: wow, I did not realize how similar Prime 1's AGSC format is to 2. Will have Prime 1 dumping working momentarily I think.

EDIT 3: Prime 1 AGSC dumping works as well now - just dumped the Metaree sound effects

EDIT 4: Anyone recognize this thing from Prime 1? It's labeled "Torobyte", and I do not recognize its sound effects at all. Have a listen: https://drive.google.com/file/d/0B9MLV21H7SDvRXpXOEs1ejVuX2c/view

Also, there's a weird dial tone sound effect that's been in every Prime 1 AGSC I've dumped so far. Not sure what's up with that.

EDIT 5: Working on a tool that decodes a couple Prime series audio formats, including AGSC. Should hopefully have it up soon, hopefully tonight but if not then tomorrow.
OMG, YES!!!!  Thank you so much, Paraxade!!!  Can't wait to finally have some Tallon Metroid sound effects!!

I don't recognize the Torobyte sound effects either, interesting...

How does AGSC work?
Edit history:
Aruki: 2014-10-07 02:18:29 pm
Aruki: 2014-10-05 10:24:08 pm
OKAY here's the tool - attached to this post, or alternately, download here! It supports AGSC, DSP (from Prime 1 only - Prime 2 DSPs break), and CSMP. Sorry if there's any bugs - it's kinda messy honestly and just spun off from audio format learning/practice, heh.

So how AGSC works - as we've already established several times, there's four distinct data chunks. The difference between Prime 1 and 2 AGSCs is the way the chunks are organized. First of all, the headers are different. Prime 1 starts with a directory and then subdirectory string, then each chunk in order, each one starting with its size value. Echoes, on the other hand, starts with a 32-bit value that is always 1, then a subdirectory string, then a 16-bit value; after that, the sizes for all four chunks are listed one after another. The four chunks begin after that. The other main difference is that in Prime 1, chunk 3 is ADPCM data and chunk 4 is sound info. In Echoes, it's the other way around - chunk 3 is sound info and chunk 4 is ADPCM data. The way the data in those chunks is actually organized is identical between both formats; they're just in different places.

Now, I still have no damn clue what chunks 1 and 2 are for, nor how to parse them. My best guess is a scenegraph. In any case, it turns out we don't actually need them to decode sounds, so screw them. The sound info chunk is the important one. It has two tables of sound info. The first table has one entry per sound in the file, and contains an offset to the corresponding entry in the second table. I don't know of any sound count within the file, but the table is terminated with a value of 0xFFFFFFFF, so you can just read until you hit that terminator and then break out. The tables are structured like this:

Code:
struct sound_info_A {
    u16 soundID; // ?
    u16 pad;
    u32 sound_start_offset; // Relative to the beginning of the ADPCM data section
    u32 unknown1;
    u16 unknown2; // Always 0x3C00 (15360)?
    u16 sample_rate;
    u32 sample_count;
    u32 loop_start_sample;
    u32 loop_length;
    u32 sound_info_B_offset; // Relative to the start of the sound info section
};

struct sound_info_B {
    u16 unknown1;
    u16 unknown2;
    u32 unknown3;
    s16 coef[16];
};


The actual sound data is standard DSP ADPCM; it can be decoded exactly the same way as a DSP file. The sounds are stored in order, although the size of each sound is always a multiple of 32; so if you read them through without using the offsets for some reason, you need to skip ahead from the last sample to accurately reach the start of the next one.

That's about all you need to extract/decode sounds. As far as the format though, we're still missing basically everything in chunks 1/2, and we might need whatever it is for custom AGSCs.

Shoutout to vgmstream; even though their implementation for AGSC is incorrect, it gave me a good idea of where to find the sound metadata :P

There's some interesting stuff in the MP1 demo as well, including a bunch of sound effects from the cut Sova (the final has a few too, but not as many, and none of the interesting ones), so you guys should have a look through there if you have it.

edit: If you're interested in also having text dumps of metadata and offsets related to each sound effect, use the download link at the top of this post, or see this post.
attachment:
Awesome, thanks so much Paraxade!  If you don't mind, if you could please add loop points to the WAV files, that would be amazing and greatly appreciated.  After doing some research, it looks like WAV loop point work by placing the loop position byte offsets in the smpl chunk.  The loop points are stored as little endian in the WAV, so the bytes are backwards compared to how the loop points are stored in the Nintendo DSP header.

http://www.sonicspot.com/guide/wavefiles.html
http://www.blitter.com/~russtopia/MIDI/~jglatt/tech/wave.htm
I'll look into it tomorrow sometime.