-
Welcome to Smashboards, the world's largest Super Smash Brothers community! Over 250,000 Smash Bros. fans from around the world have come to discuss these great games in over 19 million posts!
You are currently viewing our boards as a visitor. Click here to sign up right now and start on your path in the Smash community!
Melee dat format...
- Thread starter revel8n
- Start date
Well when you display the object it has to disappear at some point right. Theres probably a function to remove them. Like YLs taunt displays a bottle, but some function has to remove the bottle. Im curious about that function.
Tcll
Smash Lord
not really, because I lack understanding of materials/TEVs
but to explain the BP register, since that's where all the color arithmatic is done, think of it as a sort-of functional (pseudo) fragment shader.
Brawlbox devs have their thumbs up their butts since they call the TEVs "shaders" and they're not.
the BP interface is only functional, not programmable... shaders are programmable.
tbh, I'm really not too sure if the BP register actually has any sort of effect...
although if it does, it's likely defined in a function in the DOL.
SinsOfApathy
Smash Journeyman
- Joined
- Feb 24, 2015
- Messages
- 474
- NNID
- Psion312
Might find some luck in http://smashboards.com/threads/foxs-functions.409379/
Under special neutral, I pointed out Fox's functions related to despawning the gun. I think I actually have the function that it calls as well, but not in a place to check.
So it seems that the game looks at the order of bones and objects to performs transformations on them as indicated probably by the joint matanim section. If you add things to the end of the list then the game doesnt fuss. Currently just added a sibling bone to the last bone in a root structure and the game accepted it without adding the visibility bone aspects like transparency and the bouncing animation. That being said I dont know if the transformations done to the bone itself carry over.
First off, I'd like to say that this thread is awesome. I haven't had time to play with the stuff in here or even read it all yet, but this is stuff we've needed for a while. I have a question though, which has finally led to myself getting involved. You know how tpl files are able to contain multiple textures (even though this is pretty much never seen, since Dolphin doesn't appear to ever dump them with more than one)? Well, what I want to know is, how is this represented in a DAT file? I suspect they're used for two purposes: mipmaps, and animations (cases where a texture is swapped out for another slightly different one after a frame or two, like with dust textures). I think that the data for these is stored end-to-end, so essentially it's actually just one larger image, like a spritesheet. But I don't know if there are separate headers. If they exist, they must be in a different format, perhaps similar to the matanim tables I described before. Reason being, I can't seem to find some headers for some textures. For example, for some textures I had dumped and located a long time ago (EfCoData spreadsheet):
Second column is the offset range (start to end), third column is the data length.
I find it really strange that I couldn't find anything pointing to at least the start of the first texture's image data. Any ideas?
Second column is the offset range (start to end), third column is the data length.
I find it really strange that I couldn't find anything pointing to at least the start of the first texture's image data. Any ideas?
Probably works like the mdl0's mipmaps. There might be a flag with a version number and number of images in the material or texture structure. Id have to see a mipmap texture header/material struct though to confirm.
Achilles1515
Smash Master
Yoshi's Story Mipmaps
Placement as referenced by Steelia:
Image Structure (highlighted):
Note: I really don't know much about mipmaps, nor what Steelia means by "0,8,0", but I assume that the floating point value of 0x41000000 = 8 at offset 0x14 of the Image Structure is a reference to this value.
Material Structure (highlighted):
Note: 0x14 of the Material Structure is a pointer to, what looks to be, a flag structure of 0xC in length.
-----------------
For another mip texture on Yoshi's, Steelia gives the placement data as:
Image Structure:
Note: Floating point value of 0x40E00000 = 7, as referenced in Steelia's placement data.
Placement as referenced by Steelia:
Code:
27 - 00081c20 MIP -- 0, 8, 0Note: I really don't know much about mipmaps, nor what Steelia means by "0,8,0", but I assume that the floating point value of 0x41000000 = 8 at offset 0x14 of the Image Structure is a reference to this value.
Material Structure (highlighted):
Note: 0x14 of the Material Structure is a pointer to, what looks to be, a flag structure of 0xC in length.
-----------------
For another mip texture on Yoshi's, Steelia gives the placement data as:
Code:
20 - 0008cf20 MIP -- 0, 7, 0Note: Floating point value of 0x40E00000 = 7, as referenced in Steelia's placement data.
Last edited:
Achilles1515
Smash Master
Arbitrarily modifying that color/transparency flag structure from above. First picture is the default value.
Last edited:
Achilles1515
Smash Master
Alright, so now looking at some Assembly code.
Image Structure:
0xC = unsigned, flag (looks to only be checked for if zero or not zero)
0x10 = float, unknown (typically 0?)
0x14 = float, unknown (referenced in the mipmap textures above)
-------------------------
0x18 = unsigned flag or something. first bit seems to be of importance
At some point in the ImageStructure_Parse function, it checks this flag to see if it is equal to 5.
If so, it changes it to 3 and then branches to Part X of the function.
If not 5, it branches to Part X
(I don't believe this part of the code is executed for every image type)
Part X:
first thing it does is check to see if imagestruct+0xC = 0. If so, the value from above is changed to whatever the first bit is (0 or 1).
If 0xC is not zero, nothing is modified to the flag.
------------
I'm interested into digging more into this function (80360950) but it's complicated and giving me a headache at the moment.
Tcll
HAL DAT Format updates
Image Structure:
0xC = unsigned, flag (looks to only be checked for if zero or not zero)
0x10 = float, unknown (typically 0?)
0x14 = float, unknown (referenced in the mipmap textures above)
-------------------------
0x18 = unsigned flag or something. first bit seems to be of importance
At some point in the ImageStructure_Parse function, it checks this flag to see if it is equal to 5.
If so, it changes it to 3 and then branches to Part X of the function.
If not 5, it branches to Part X
(I don't believe this part of the code is executed for every image type)
Part X:
first thing it does is check to see if imagestruct+0xC = 0. If so, the value from above is changed to whatever the first bit is (0 or 1).
If 0xC is not zero, nothing is modified to the flag.
------------
I'm interested into digging more into this function (80360950) but it's complicated and giving me a headache at the moment.
Tcll
HAL DAT Format updates
Last edited:
Yep, resembl
http://wiki.tockdom.com/wiki/TEX0_(File_Format)
Its best to try and find an equivalent structure in brawls format first since the files are very close in nature and theyve had a lot more manpower researching this stuff.
Looks exactly like the tex0 header.Yoshi's Story Mipmaps
View attachment 75626
Placement as referenced by Steelia:
Image Structure (highlighted):Code:27 - 00081c20 MIP -- 0, 8, 0
View attachment 75628
Note: I really don't know much about mipmaps, nor what Steelia means by "0,8,0", but I assume that the floating point value of 0x41000000 = 8 at offset 0x14 of the Image Structure is a reference to this value.
Material Structure (highlighted):
View attachment 75629
Note: 0x14 of the Material Structure is a pointer to, what looks to be, a flag structure of 0xC in length.
-----------------
For another mip texture on Yoshi's, Steelia gives the placement data as:
Image Structure:Code:20 - 0008cf20 MIP -- 0, 7, 0
Note: Floating point value of 0x40E00000 = 7, as referenced in Steelia's placement data.
http://wiki.tockdom.com/wiki/TEX0_(File_Format)
Its best to try and find an equivalent structure in brawls format first since the files are very close in nature and theyve had a lot more manpower researching this stuff.
I found some interesting structures. Of the group of electricity textures I posted above, I found this header/table right before the first texture, at 0x74220:
And then this appears directly after the last texture, at 0x78A60:
But the pointers in neither of these point to the electricity textures between them. (And there is nothing but image data between them.) :/
They still appear to be a table of image data pointers though. To be more precise, it looks like:
Offset|Size (bytes)|Description
0x0|4|Number of textures in table (N)
0x4|4|Texture type
0x8|4|unknown
0xC|4|width or height
0x10|4|width or height
0x14|4|unknown
0x18|N*4|image data entries
0x3C|4?|unknown
There are a lot of headers/tables like these throughout the file. Though some are strangely slightly different, like these:
There's also a common similar structure that's only 0x20 long.
Guess this is all different than mipmaps.
I still don't understand why I can't find pointers or headers to those electricity textures (as well as other textures in this file). I'm not sure yet if these headers/tables above exist in other files, but I haven't seen them before. I don't think they're in character or stage files anyway. And probably not trophy files.
WAIT! STOP THE PRESSES!
Ok, while writing this I think I figured it out. If so, the pointers have been sitting here all along. I think they might be that first group in this post above. But then they're not relative to the start of this file's data section! They would be off by 0x11C00. Ugh, why is this file so weird? It's gotta have something to do with what these textures are used for. Or more specifically, how they're used.
Anyway, the reason I'm thinking that structure corresponds to the electricity textures is because the pointers are 0x800 apart (the length of the textures), there are 9 of them (which is how many textures appear before the next header/table), the image type and width/height corroborates, and then one more thing, which changed my mind from the rest being coincidence: one of the pointers included is 0x063E40. But that can't be right, because there's actually image data for another texture there, from 0x5C220 to 0x6421F.
And another thing, the second header/table I posted that comes after the electricity textures has 6 entries. And sure enough, it looks like there's a group of 6 images following it. Image type, width/height, and data length between pointers all match. And the mystery offset is the same.
0x11C00, what are you?
Code:
00 00 00 09 00 00 00 00 00 00 00 00 00 00 00 40
00 00 00 40 00 00 00 00 00 06 26 40 00 06 2E 40
00 06 36 40 00 06 3E 40 00 06 46 40 00 06 4E 40
00 06 56 40 00 06 5E 40 00 06 66 40 02 4D 30 40
Code:
00 00 00 06 00 00 00 03 00 00 00 00 00 00 00 40
00 00 00 40 00 00 00 00 00 06 6E 80 00 06 8E 80
00 06 AE 80 00 06 CE 80 00 06 EE 80 00 07 0E 80
00 00 00 00 00 00 00 00 00 00 00 00 02 51 2D 50They still appear to be a table of image data pointers though. To be more precise, it looks like:
Offset|Size (bytes)|Description
0x0|4|Number of textures in table (N)
0x4|4|Texture type
0x8|4|unknown
0xC|4|width or height
0x10|4|width or height
0x14|4|unknown
0x18|N*4|image data entries
0x3C|4?|unknown
There are a lot of headers/tables like these throughout the file. Though some are strangely slightly different, like these:
Code:
@0xB50C0
00 00 00 03 00 00 00 01 00 00 00 02 00 00 00 20
00 00 00 20 00 00 00 00 00 0A 34 E0 00 0A 38 E0
00 0A 3C E0 00 00 00 00 00 00 00 20 02 17 01 A8
00 00 00 00 00 00 00 00 00 00 00 00 02 5E 77 A0
@0xD4500:
00 00 00 03 00 00 00 03 00 00 00 00 00 00 00 40
00 00 00 40 00 00 00 00 00 0C 29 20 00 0C 49 20
00 0C 69 20 00 00 00 00 00 00 00 20 02 17 01 A8
00 00 00 00 00 00 00 00 00 00 00 00 02 62 BC E0Guess this is all different than mipmaps.
I still don't understand why I can't find pointers or headers to those electricity textures (as well as other textures in this file). I'm not sure yet if these headers/tables above exist in other files, but I haven't seen them before. I don't think they're in character or stage files anyway. And probably not trophy files.
WAIT! STOP THE PRESSES!
Ok, while writing this I think I figured it out. If so, the pointers have been sitting here all along. I think they might be that first group in this post above. But then they're not relative to the start of this file's data section! They would be off by 0x11C00. Ugh, why is this file so weird? It's gotta have something to do with what these textures are used for. Or more specifically, how they're used.
Anyway, the reason I'm thinking that structure corresponds to the electricity textures is because the pointers are 0x800 apart (the length of the textures), there are 9 of them (which is how many textures appear before the next header/table), the image type and width/height corroborates, and then one more thing, which changed my mind from the rest being coincidence: one of the pointers included is 0x063E40. But that can't be right, because there's actually image data for another texture there, from 0x5C220 to 0x6421F.
And another thing, the second header/table I posted that comes after the electricity textures has 6 entries. And sure enough, it looks like there's a group of 6 images following it. Image type, width/height, and data length between pointers all match. And the mystery offset is the same.
0x11C00, what are you?
Thats how sections work in the mdl0 format and the pl**aj files work that way as well. The headers are relative to the start of the section. Same should apply to whatever pointer led you there.
Also could we move this conversation to the dat file research thread. Its really what its for.
Last edited:
I see. I've never looked at files that didn't have the standard 0x20 offset for everything, so I was really confused for a while. I'm still not sure why I can't find a pointer to the headers/tables that I outlined, even with the 0x11C00 + 0x20 offset.
lmao, yeah, actually that's where I intended to post this in the first place. But I had both tabs open and accidentally posted in the wrong one. If
Achilles1515
feels like it, he has my permission to just move all of my posts here to that thread, so the research is all together. Of course, for it all to make sense I guess he'd have to move the responses too. Or I could just repost it.
Last edited:
Id appreciate if he did lol. Id have to look at the file or Ill probably give you some false leads on what to do. After I figure out a few things with the imports.I see. I've never looked at files that didn't have the standard 0x20 offset for everything, so I was really confused for a while. I'm still not sure why I can't find a pointer to the headers/tables that I outlined, even with the 0x11C00 + 0x20 offset.
lmao, yeah, actually that's where I intended to post this in the first place. But I had both tabs open and accidentally posted in the wrong one. If
Achilles1515
Smash Master
Material Structure unknown flags at 0x4
If the first byte of the flag word contains 0x20, then the object seems to get sent to the back.
If the first byte of the flag word contains 0x04, then the object is able to have a shadow cast on it.
But it doesn't work quite right, as you can see the shadow is on the underside of the top platform as well.
Below I added the shadow flag to the top surface and sides of the Gamecube. I don't know how to fix this problem.
If the first byte of the flag word contains 0x20, then the object seems to get sent to the back.
If the first byte of the flag word contains 0x04, then the object is able to have a shadow cast on it.
But it doesn't work quite right, as you can see the shadow is on the underside of the top platform as well.
Below I added the shadow flag to the top surface and sides of the Gamecube. I don't know how to fix this problem.
The next half-word is what Ive really been playing with. The first half word makes arbitrary changes and I cant figure it out. Ive just been just 0x40 because 0x00 doesnt support alpha. 0x11 or 0x12 does something really weird in the next half-word. Anything over 0x14 for the next half-word applies shading to the stage.
Ive try 0x4 for the first half-word though, If it still supports alpha it I might use it over 0x40.
0x04 supports alpha. It also gives me a solution to a problem. While not a solution to the problem in general, for battlefield at least if I make EVERY other material struct flag 0x04 and the waters 0x40 the water shows. Its something to do with draw order.
Achilles1515
Smash Master
Last edited:
Yeah Im rebuilding the file again testing what breaks. Making the whole file again takes too long so Im just doing the platform over and over.
If you notice though, every time a hit is connected the platform flashes as well and flickers if you kill off the top.
Probably not the best thing to test with since it doesnt have really any shading to begin with lol. I did the base platform again. Ill upload it in a sec.
Last edited:
Achilles1515
Smash Master
Well I can tell you it flashes because the third bit is set high in the last byte of the flag word. So changing it from 0x3c to 0x38 fixes the problem.
But I can't really tell you anything further, other than the platform looks amazing.
Last edited:
Achilles1515
Smash Master
Let me know how it goes.
It makes it now only flicker white. Also gets rid of the shading
Last edited:
Achilles1515
Smash Master
map_head
+0x28 = pointer, start of table of material structs pointers to automatically apply shadows to during stage loading.
+0x2c = unsigned, number of material struct points in table (1-indexed)
Function that controls autoshadowing is 801c6228.
It loads the material structure flag word and then or's it with 0x04000000.
+0x28 = pointer, start of table of material structs pointers to automatically apply shadows to during stage loading.
+0x2c = unsigned, number of material struct points in table (1-indexed)
Function that controls autoshadowing is 801c6228.
It loads the material structure flag word and then or's it with 0x04000000.
Last edited:
Oh so that might be it. Theres no material index for the section I created.
Edit: No luck there. Zeroing the index removed the shadows but didnt produce the flickering effect Im getting. It changes the lighting on the stage though. Whatever the problem is, its not going to be figured out over night since it looks as though it lies in some unknown sections. What gets me though is that characters dont have this struct and still have shading.
Last edited:
@achilles. When you get a chance can you look into the table at the beginning of the file. Its related to camera/spawn stuff. The first pointer in the root section always has the camera/spawn/blastzone bone struct and it always points to that table so my theory is that the table tells the game which bone does what. Otherwise the game would just have to know somehow to use which bones as spawns. Thought this would be easier than trying to remake the file using a table and bones from a different stage but Im not quite sure how youre testing this stuff.
Achilles1515
Smash Master
Tried a little bit tonight. Didn't really find anything substantial and got super sidetracked following random code.
I booted up Hyrule 64 on Dolphin and it looked very good. Your work is great.
Thanks, one day we'll have shading.
I know that if you zero the table at the beginning you remove the spawns.
@achilles when you originally moved the platforms for battlefield you said something about them being stored in a different format. Can you go into that a bit and how you found it. I believe what you found is related to area tables. Basically when I tried importing collisions into 1 file that game broke and I believe its to do with the area tables so I want to look into it.
Achilles1515
Smash Master
No, I know about the area tables. I was talking about where the game is reading collision data mid-match in the RAM. It looks a little different than the table of floats that you edit in the DAT for collision points.
I was reading up on what the brawl table is used for and apparently area table is what the game uses for collisions mid match. I didnt really follow much further but it sounds similar to what you found in that the collisions should be tied to the area table somehow. I did an import over groy and it breaks. I suspect that its because I changed the area table and how the game reads the area table and the disappearing clouds.
Achilles1515
Smash Master
My understanding of the Area Table:
All the area table [an imaginary rectangle(s)] does is allow stage collisions to occur (correctly) in that region. That is the only function I have ever seen it play. If a collision link exists outside of any defined area table, it won't do anything. If a collision link (floor) extends outside an area table, then the portion inside will work as normal, but the portion outside can be walked out to like normal, but will be passed through and ignored by characters falling on top of it.
The disappearing clouds for Yoshi 64 are controlled by ASM code, likely from supporting data in the stage file. I don't know the nature of the "break" you caused, but I would guess it to be something related to game code controlling bones, more so than the area table. I'm not sure if you can cause the game to freeze by strictly modifying the area table (with legitimate floating point values).
Last edited:
It broke only from importing the coll data. The same imported coll data worked on a different stage. It doesnt make sense that it would be the collision points or links which is why I believe its the area table. Brawl modders concluded that the only reason why theres not 1 big area table normally is for platforms that undergo some transformation and they just make a big 1 for stages that dont have any but use multiple for things that undergo transformations. I guess I could just set a break point at the area table and see what the game does with it.
Last edited:
Achilles1515
Smash Master
Hmm alright. I posted that same thought somewhere here in the forums a while back, asking “why isn’t the area table just the size of the blastzone?” I’m not sure why the area table would affect the cloud; it looks like the collision link just gets removed when it disappears. But I do bet the area table is meant to be used for dynamically changing stages, otherwise is just wouldn’t make sense.
Also, idk if you were on your hiatus or not when I posted this about how to change the BGM in the stage DAT file.
That's incredibly useful. I was just complaining to myself about how the target stage music wasnt fitting at all.