[$threadinfo[title]]

[thakis]

Hi,

I've written a program that extracts all data from .szs files (found in supermariosunshine for example), get it with source and documentation from

http://www.amnoid.de/gc/szstools.zip

Post to this thread if you find out what's stored in all the files that are generated from the szs/rarc files :-) Some wild guesses by me:

.bmg: Messages/Subtitles. Contain lots of text.
.bmd: 3d model data?? Contains "VTX1" blocks which could stand for "Vertex". However, most of these files are not too big. The "map/map" subdir of the szs files in "data/scene" contains a map.bmpd which is quite big (nearly always > 1mb), this could be the main level model.
.jpa: Texture/Image??
bmt: Material??

Bye,
thakis

[edit: fixed link :-O ]

[MGFox]

Good Work, and Welcome to the EmuTalk Forums! :happy:

Just to let you know, the yaz0 compression in the SZS files is also used in the REL files on Wind Waker. I suppose it's highly possible that its been used in other games as well, just with different extensions!

Cheers,
Fox

[thakis]

Hi,

I've managed to extract most of the texture data from the .bmd files (currently only s3tc1 compressed data is extracted, but most textures are in that format. It seems that the format byte has the same meaning as in .tpl files, so I hope I can extract the other formats soon, too). I will post an exe for it when I managed to extract the vertex/face data as well (it's stored in the .bmd files as well).

[thakis]

Hi,

here's a tool to extract textures from .bmd files:
www.amnoid.de/gc/bmdview.zip
(see included text file...)

Cheers,
thakis

[thakis]

Status update (first mario level): :bouncy:

[MasterPhW]

NICE! Really nice...

[thakis]

As you can see, tristrip loading kinda works now, too. I managed to decode which kind of data is stored in the model (colors, texcoords, normals, ...), but the viewer has not yet been updated to use this additional information, so the tris are grey...

Things still missing:
- I don't know how many normals/texcoords/colors are stored in the file. I could let the program count them, but it's gotta be stored somewhere in this file as well...
- There are different kinds of tristrips in a single model: some tris have only normals while others have normals and texture coords. I don't know at which boundaries tristrip types change - so only the first "type" is displayed right now (that's why not the whole scene below is triangulated).

I'll take a creative break tomorrow, I hope I'm able to display textured, lighted and colorful models this weekend :canadian:

[MGFox]

Dude, this progress is amazing, excellent work!

I know this maybe a stupid question, but would there be any possiblity of a guide to reverse-engineering file formats? I would love to help you out, but I've only ever reverse-engineered settings files (e.g. DAT files) so this is VERY different!

Cheers,
Fox

[thakis]

Hm, basically I open a file in a hex editor, look at it until I see what some of the bytes could mean, write a little program to test it my assumptions work, and if it works for about 5 different files I assume that my guess was right and I move on to the next block.

When I've finished decoding the vertex data, I'll post a document that describes the .bmd format and another one that describes which of the files helped me most to understand the format and what I learned from which file. Hopefully this weekend... :-)

[Guru64]

Sounds great! Remembers me of Sanik, he was hacking the Sonic Adventure models.

Well, good luck.

[thakis]

Getting somewhere...
Took me some time, but now I understand the tristrip data format well enough to display triangles for the whole scene - here is a screenie. Theoretically textures and normals are now working as well (the normals used in the screenie weren't loaded from the file but computed from the triangle data), I just have to implement it (but I know where to read the data from in the file).

Next steps are support for animated models (they still look somewhat horked because I need to take joint data into account for them, what I'm not doing at the moment [and I don't understand the joint data format at the moment]) and support for models with more than one texture.

[smcd]

Whoah, nice progress :)

[Azimer]

I agree. This is quite interesting. I hope more people look into making use of gamecube games in a non-emulation way. Thanks for sharing all your progress.

[thakis]

Now with colors but without lighting - seems as if the lighting is included in the vertex colors anyway.

[thakis]

Texture.

[thakis]

Textures in the airport level. Because there's only one texture per file supported at the moment, you can choose which part of the map looks correct - the rest looks kinda weird with the chosen texture :-)

Below are shots with the airplane texture and the mountain texture enabled.

[_Chrono_]

wow awesome progress thakis
is that the only scene you can view at the moment?

[thakis]

No, I thought it's nice to always use the same scene so one can better see the progress. All scenes work. Name your favorite one and I'll post a screenie ;-)

[_Chrono_]

id have to play the game to know the scenes (or levels). so any scene qould do

[thakis]

Play it, it's a great game! Here's the town (looks *really* weird 'cause it uses lots of different textures)...

[Guru64]

Man, you rock!

[Dysprosium]

Out of curiousity, is it possible to see everything in it's own proper textures? :\

Anyway, great progress. :)

[ector]

Hehe, yaz0r has already done all this and more :)
btw, Zelda WW (and mario kart dd, and pikmin I think) use the same engine so you might be able to load some of their levels pretty easily now.

[MGFox]

yaz0r has already done all this and more

yaz0r has (almost) perfected the emulation of the j3d engine (models were working before yaz0rs contribution, no?), while thakis is creating a file/model viewer, Quite Different :huh:

Although, the picture in "this post" (http://www.emutalk.net/showpost.php?p=257092&postcount=14) (along with his Avatar) suggests that yaz0r has also written a model viewer! :doh: If this is correct, is it gonna be released as part of Dolphin, separately or...at all? :P

On a side note, even if something has already been done, it should not prevent someone else from persuing the same goal! There are many GCM viewers/extractors out there, I still wrote my own to see if I could!

Cheers,
Fox

[yaz0r]

This would probably look better with the actual textures :)

I don't know if I ever will release my J3d stuff, as nitendo is probably owner of the techonology and even used it in the GC bios and recent games as DK jungle beat....

[MGFox]

:w00t: Whoa!!! I think that answers my question! :P

Is releasing a model viewer against copyright? as long as you don't release any copyrighted material with it, it's no different then releasing an emulator! And the groups that made model viewers/editors for Quake, Half-Life and Doom3 have never had any problems!?! :huh:

I'm not an expert on legal matters, so please feel free to correct me! :whistling

Cheers,
Fox

[thakis]

I just wanted to say that I'm still working on this, even if yaz0r has done this before. I'm currently finishing joint support, something I could never have finished without yaz0r's help (to show you that's not that easy, here's a line from the source: "m = g_matrices[g_drawData.indices[curr.matrixTable[curr.tristrips[i][j].matrixIndex/3]]];" - and in this line two levels of indirection are already precalculated. Try to see 5 levels of indirection just by looking at a hex dump! :-)). Here are two images, one without and one with joint support (it only makes a difference for animated models, though).

After that I'll take a look at materials or animations.

[JinXD]

Glad your still working on this, be nice to play with :D

[thakis]

By now, all geometry loads correctly (at least for all the files I tried...). Below are some images showing how mario evolved over time. In this order:

- Vertices only, but displayed all wrong
- Raw face data, but some faces are missing (I can't code...)
- Raw face data, complete
- Basic scenegraph support
- Support for tristrips that require several matrices
- Same as before, but with "skinned" vertices (more than one bone may influence a vertex) (but this didn't change the appearance) and default values for undefined matrix indices (some matrix indices are stored as 0xffff in the file) (this fixed the appearance).

[thakis]

I decided to do animations before materials (mainly because that's something yaz0r has not yet done ;-) ) and it turned out to be quite easy. The animations are stored in the .bck files. Here's a screenshot of yoshi walking (animations don't look to impressive in screenshots, I know...), all animations that I tried (mario walking, rolling, jumping, some yoshi moves etc) seem to work. Materials next.

[smcd]

Keep on hackin it man :)

[thakis]

My material support is not (yet?) nearly as complete as yaz0r's, but it's at least somewhat working:

[ShizZy]

Wow, that's pretty impressive. Keep it up!

[thakis]

I was searching for a file that contains information where objects are to be placed in a map (so the palm can be displayed in a level trees, for example). I haven't found this file yet, but I "accidentally" decoded another file format - .ymp. It seems that .ymp files store some kind of heightmap information with white being some special value. For each level a "ymap.ymp" file is stored..if anyone is interested, I can post documentation on this format and a converter that converts a .ymp file to a few .bmp files which you can view with your favourite image viewer. Perhaps you have an idea what this files could be used for...

Here's an example image (obviously it's the "main place" in the town - where the entry to the first level ist):

[thakis]

I've written a 3d viewer for .ymp files because you can't really tell how a heightmap looks by looking at its grayscale image...still no idea what these heightmaps could be used for. As said before, if anyone is interested, I can post its exe and source...
0xff is interpreted as height 0 in the images below (might not be right), the first image is the the 3d view of the above grayscale image:

[yaz0r]

still no idea what these heightmaps could be used for.

This is probably used for collision computation with the background.

[thakis]

Possible, but the heightmaps contain only a part of a level (and different parts for different missions in a level) and some levels have no heightmap at all. Additionally, there are .col files which might store collision geometry.

Btw.: I think I found out which file stores where objects are to be placed in a level...it's probably the scene.bin file in the map directory of every level.

[Lomax]

Interesting stuff here!

Maybe the heightmaps are used for terrain changes? I remember several areas where the terrain would change as you cleaned it up...

[sonicadvance]

This seems to be interesting.way above my programming level but keep it up, hope you release it soon :)

[thakis]

Hi, I need someone who can read japanese. Can you tell me if the text in the following image is sensible japanese? If so, can you translate it for me? TIA.

(If it is japanese, then strings are stored as shift-jis [sjis]...would make me wonder why they don't use utf8)

Edit: I'm pretty sure this is japanese...would still be nice if someone could confirm.
Edit2: Lomax: This sounds like a really good idea...fits for the files I tested :canadian:

[Elly]

Hi, I need someone who can read japanese. Can you tell me if the text in the following image is sensible japanese? If so, can you translate it for me? TIA.

(If it is japanese, then strings are stored as shift-jis [sjis]...would make me wonder why they don't use utf8)

I am not the best translator, but here's my humble try :

1. Whole scene
2. *something* conductor ( Cant be arsed to look up the kanji ;P )
3. Item Manager
4. Shine(?)/Schein(?) Manager
5. Terrain ( or Map ) Object Manager
6. Tree (?) Manager
19. Secuial (??) scene
20. Indirect scene

I ll translate the remaining ones later on ... ( I ll be editing this post ).

PS : Yes, this is japanese.

edit : bleh, the post below me explained it better ;)

Yours,
-Elly

[Lomax]

Here's my attempt -

GroupObj "the entire scene"
GroupObj "conductor early days/first stages, transform/change, use/business errand" (can't make sense of it)
ItemManager "Item Manager"
MapObjBaseManager "Shine Manager"
MapObjManager "terrain shape OBJ Manager"
MapObjBaseManager "Tree Manager"
MapObjBaseManager "large-size terrain object manager"
MapObjBaseManager "Far clip terrain object manager"
MapObjBaseManager "vehicle/aircraft manager"
PoolManager "water area manager"
HamukuriLaunchManager "Hamukuri Launch Manager"
EffectObjManager "Flame Effect Manager"
BoardNpcManager "sign NPC manager"
GroupObj "Mirror scene"
MirrorCamera "Mirror Camera"
MirrorModelManager "mirror surface model control"
MapObjWave "wave"
GroupObj "Specular Shine"
GroupObj "Indirect Shine"
MarScene "Normal Scene"

[yaz0r]

My material support is not (yet?) nearly as complete as yaz0r's, but it's at least somewhat working:

Btw, you're going to need a complete pixel shader setup to have a working TEV emulation.

This shot ( http://www.emutalk.net/attachment.php?attachmentid=21412&stc=1 ) was made using a ripoff the dolphin pixel shader code to properly emulate the TEV setup.

[thakis]

I played a bit with supermario sunshine's video files (.thp, they are not stored in szs files, so this does not really belong in this thread)...here's a first screenie. Not too impressive ;-)

[thakis]

Now most frames work...I'll try to write a player and post it here...

[JinXD]

That is pretty sweet!! Keep it up ;)

[Guru64]

Is the .thp format used in Super Mario Sunshine the same as the .thp format used in other Gamecube games?

[thakis]

I don't know, but probably. I'll post a viewer in the next hours (say, about 5), you can try yourself and post your results then.

[thakis]

Here's a thp player for you (with source if you want to take a look):
http://www.amnoid.de/gc/thpplay1.0.zip
You only need the .exe to run it...associate it with .thp files and/or drag thp files onto the window to play them.

Supported games so far: Mario Sunshine, Zelda Wind Waker, Mario Kart Double Dash (according to Knuckles, who beta-tests every single gamecube app out there ;-) )

Two screenies:

[Knuckles]

thp currently tested/supported that are in the following games:


-Custom Robo
-Mario Sunshine
-Mario Kart : Double Dash
-Pikmin 2
-Pokemon Colosseum
-Zelda 4 swords
-Zelda Wind Waker

NOT SUPPORTED:
-Super Smash Bros Melee
-StarFox Adventure

[posty_2k3]

Metroid Prime 2 works for videos.

[_Chrono_]

wow im lovin this :) good job thakis.
heres what i tested...

Works:

1080 Avalanche
Aquaman: Battle for Atlantis (one doesnt work though....)
Beyblade V-Force
Final Fantasy Crystal Chronicles
Megaman Network Transmission
Mission Impossible Operation Surma
Mobile Suits Gundam Pilots Locus
Pokemon Collosseum
PN03
SpongeBob SquarePants

Doesnt work:
(Something about it not being a JPEG...)

4x4 Evolution 2
Mario Party 4
Rocket Power Beach Bandits


Thats it for now... i would post pics but its kinda late and im lazy. once again good job thakis :)
I noticed alot of games are using the .h4m format for movies. Will you try and look into that format also? ;)

[Nuusika]

Very Good Job! Can you add sound-support on that video-player or is it impossibble?

Btw, I want to ask, when you release that model viewer? It's looks also very good

[Guru64]

Sweet! I'll try it with some of my games later.

EDIT: Just tested it. It rocks!

Works:

Doshin The Giant
Ikaruga

[thakis]

Nice that that many games work :-) I only own Supermario Sunshine, so I can't take a look at the non-working ones, but I guess most of them could work as well with a few extra lines. If you want, you can take a look at the files in a hex editor (I use frhed, http://www.rs.e-technik.tu-darmstadt.de/applets/frhed156.zip . Use "Open partially..."... ). If the file start with 'THP' (that is, the bytes 54 48 50) it's a "real" thp file, if it starts with ff d8 it's "nearly" a jpeg file (take a look at thpplay's source if you want to know what that means ;-) It's less than 500 lines and well documented...). In these two cases it should be easy to add support for them. If the file starts with something different, it's probably more difficult.

I'll take a look at sound, but I don't know when. The next thing I'll probably do is add subtitle support for the videos (because I hope I'll learn how a file references another file [the subtitles are stored not directly in the thp...]), after that I'll either take a look at sound or continue level loading.

I can't take a look at .h4m files because I have no file in this format (this might change in the future, though).

I don't know when I will release the model viewer. As I said before, yaz0r helped me with joints and materials and he doesn't release his viewer, so I feel it's not right if I release mine. Perhaps I will release it without joint and material support, but I won't think about this before my viewer is somewhat easier to use (currently there are two programs: one parses a bmd file and writes a temporary file, and then another program reads that temporary file. This was sensible when I was using only a few parts of the information in the bmd file, but now it's rather pointless - and there are other quirks as well).

HTH :canadian:

[thakis]

starfox kinda works now too...i'll post a new release in the next few days

Edit: Seems as if this fixed 4x4 Evolution 2, Mario Party 4 and Rocket Power Beach Bandits as well :-) (thanks to knuckles and _chrono_ for their help :-) )

[CKemu]

Various Shots from the THPs found in:

Final Fantasy - Crystal Chronicles [GCCE 8142] (U)
The Legend of Zelda - The Wind Waker [GZLE C068] (U)

Fantastic Program :D

[CKemu]

10 More just for the hell of it, that and FFCC looks pretty (Shame about the lack of story and mind numbing gameplay)

[Knuckles]

it would be better if the games themselves would run like this on emus :P

[CKemu]

Yeah indeed :D One day they will though....one day [taps foot].

[thakis]

Here's an updated viewer. It should now support the thp files which were previously reported not to work, and .mth files should work as well. I hope there are no regressions...get it here:
www.amnoid.de/gc/thpplay1.1.zip

Knuckles reported that this version plays back videos too slow but the old version had this problem as well (I guess that is because the windows timer has a resolution of only 18 millisecs and my timing code is not very clever [= not existent]).

I've been looking at sound support, but not much progress until now...

[thakis]

This is the collision data of the first level (note the big wall around the level...). Collision data is stored in .col files (no big surprise :P ). If anyone is interested I can upload a viewer for the collision data (about 200 lines if you don't count the framework stuff).

[Ninjaro]

some shots from mario kart DD :bouncy: incredible program :w00t: :)


Mario Party 6 Works :)

[thakis]

This shows different collision groups in different colors. I don't know (yet) what the different groups are used for, I guess they have different collision behaviours associated with them (unk2 = 0x0800 probably means "start falling" for example)...

oh, and btw, please don't post more than 2 screenies of one video if it's working alright...they produce so much scrolldown :saint:

[Ninjaro]

sorrrrryyyyyyyy :whistling ok :)

[thakis]

One of the more boring status reports: I extracted the movie subtitles (and all other strings in the game...again some in japanese, but only a few), here's the text to openinga.thp (the numbers above the strings are: offset of string in data block, start frame and end frame of text in hex, type flag, start and end frame of text in dec):

Read INF1
unk: 10100, node size c, 9 strings
1 262 29e 45000000 (610, 670)
"What happened?"

10 3b6 401 45000000 (950, 1025)
"What's this icky, paint-like goop?"

33 404 427 45000000 (1028, 1063)
"It's...moving!"

42 42b 45f 45000000 (1067, 1119)
"Now now, boys! Don't touch that stuff!"

69 5ba 5f1 45000000 (1466, 1521)
"Um, excuse me, but.."

7e 6ba 6dd 45000000 (1722, 1757)
"I am most concerned with the "

9c 6dd 73a 45000000 (1757, 1850)
"well-being of the princess in
this dreadful heat."

cf 73f 755 45000000 (1855, 1877)
"Master Mario, if you would, "

ec 758 7bc 45000000 (1880, 1980)
"cross over to that shore and find
some assistance.


"

Read DAT1

Not too interesting...but easy to do ;)

[thakis]

I'm currently working on the font files (.bfn)...a lot remains to be done, but I already have the image data of one of the fonts :sorcerer:

[posty_2k3]

You on a mission to disassemble every single Gamecube file for us to view/understand? XD

Btw, nice work ;) Keep it up. Maybe some of these findings will help gamecube emulators progress, who knows XD

[dagush]

Dear Thakis:
being a programer myself, I would love to be able to study a little how they did the collision detection stuff, so I think your colored viewer could be quite interesting... could you post it?
BTW, how's the geometry/animation/texturing part going? It's been a few days since you said you almost had it...

thanks and congrats on your GREAT WORK!!!!

dagush.-

[thakis]

The colviewer is attached. Controls:
w - wireframe
d - show some info for each tri

uiojkl - rotate view

arrows and pageup/down - move
shift/control - move faster/slower
enter - "pause"
Will only work if you associate the program with .col files (or drop a .col file on the exe).
To access the .col files, you have to deyaz0/derarc the szs files (see one of my first posts on this thread on how to do that).
Tell me if you have an idea what all the unknown numbers could mean ;)

[Lomax]

I think I have an idea about the collision groups - they may be a way of limiting where the enemies can go. From what I can remember, the enemies in that level stick mostly to the grey area, they may chase Mario into a green area, but won't go into the red...

[thakis]

.blo files store layout information for ui elements (the images used in the ui are stored in .bti files, and sometimes .blo files reference fonts in .bfn files). Here's a work in progress shot of the main hud:

(edit: lomax: sounds like a good idea :canadian: )

[thakis]

I got ZeldaWW yesterday :sp_canada: , and quite a lot of files are identical to supermariosunshine files. The global file layout system is a bit different, though: In sms, there are a few yaz0-compressed szs files which contain rarc archieves. In zww, there are a lot of different files, but every one of them may be yaz0 compressed. Zelda's .arc files are rarc archieves (can be unpacked with my rarc unpacker at the start of the thread) (but they may be yaz0 compressed, just like every other zelda file). Zelda's models use a file format that's (almost?) identical to Mario's, but the file extension is .bdl instead of .bmd for some files. bti (image), bmg (messages), jpa (particles) and blo (screen ui layout) are used by both games, but in Zelda some of these files are yaz0 compressed. Zelda uses palettized images, mario does not use them (if you're familiar with yagcd: zelda uses all formats, mario doesn't use formats 6, 8, 9 and 10 [is there a format 7 btw??] - see tpl description in yagcd). Here's a shot of link and his walk animation (you can see that my material support sux by looking at his eyes ;) ).

[yaz0r]

you can see that my material support sux by looking at his eyes ;).

The eyes are very tricky and are rendered in multi-pass, especially to have them beeing draw "on top" of the hair (check in game to see what I mean).

[smcd]

Zorro Link!

[Azimer]

You can follow the second part of this thread here

http://www.emutalk.net/showthread.php?t=26919