Wells once I get these couple of fixes in the 3D done, everything will be working from the old version, but it's already far more advanced in its own respect. I suppose the only other thing I'd have to add to make it truly surpass the old version is adding the ability to export graphics to PNG etc :p
The model browser itself can disable/enable Objects, Polygons and Materials along with partial highlighting functionality by changing the vertex color to red. I'm using Maya as a basis for the UI though personally I barely know how to use Maya -_- You can also zoom in/out and perform a simple rotate of the model with the mouse, but they both need a little more work. I want to add some sort of camera control later rather than just editing the raw translate/rotation/scale variables.
The browser has had very little changed lately since I've been working mostly on specific file types, but I'm working towards adding a live preview thumbnail which would display graphics, video, sound, models and maybe more.
So as of right now supported formats are...
Archive Formats:RARC Archive (Gamecube)
ISO Image (Partial Support)
Nintendo DS Roms
NARC Archive (Nintendo DS)
WARC Archive (Wii - Initial Support)
Graphics/Palettes:BCGA (Kirby Games
BCEA (Kirby Games)
BCLA (Kirby Games)
NANR (Initial Support)
NCER (Partial Support)
NCGR
NCLR
NSCR
Sound/Video:MIDI
SDAT and its sub-types (Partial Support)
3D Modeling:BMD0 (commonly known as NSBMD)
BTX0 (commonly known as NSBTX)
Super Mario 64 DS BMD files
Along with file scanning, you should be able to see a decent amount of file support in most Nintendo DS games, unless they use a lot of custom formats.
I still need to update parts of the GUI, with some updates to graphic handling I came up with while working on the 3D stuff, along with a much needed overhaul of the hex viewer, which I have been neglecting for ages, but possibly after I've done all that as well as solidify support the all the above formats (and probably a few more by then), it might be worth releasing so other people can have a play around with it
Keep in mind though, it would only support viewing stuff and exporting it, because I'm trying do a bunch of different things at once, I'm leaving actual file editing to later, since it will require a massive amount of work to build GUIs for it :p I've got at least two months of holidays left, so hopefully I can achieve most of the above in the time I have before I get back to Uni
My current goal at the moment, is to get one of the Pokemon maps fully rendered, which would include loading multiple models at once and positioning them on the area map, and adding collision mapping
Though I also want to get Model Animations working too!
In case anyone is interested in reading up on some
Pokemon ROM Editing notes, here's the page I'm using as a reference.
[edit]
Okay I figured out what I was doing wrong...and as soon as I did, I remembered I had done it before too (déjà vu? lol). In NSBMD files, each object has a Transform Flag, and basically I was reading only one byte instead of two (hence causing some flags to result in zero). Changing this fixes the pivot/rotation factors, however there are still some other things as well. The below is old Petey, now looking much better than he did this morning, however a bit of his face is missing. Now I know I have fixed this before because I've still got the original screenshot I took a year ago, so now its all a matter of figuring out what I did to fix it. On another note, there are also still a bunch of variables I haven't implemented (mostly because I don't know what they do), which affect models from other games, such as materials for models from Phantom Hourglass. Link sadly also looks like a flag pole at the moment too -_-
[edit 2]
The problem with models like petey is that each polygon also seems to have an initial scale factor as well, which is why the first chunk of the mouth appears as though its missing, it actually is there, just not scaled properly. So far I haven't been able to isolate the exact bit of data which specifies the initial scale, but by not resetting the overall base scale value to 1 it seems to fix it on the second refresh of the screen. Not a proper fix though, and would no doubt be prone to errors once more things are added.
[edit 3]
Taking a break from models, I've started looking at model animations
Although kiwi.ds's code for reading NSBCA files is far from incomplete, it's given me a start. It's formatted in very much the same way as NSBMD and NSBTX files.
The basic structure up to where I am is as follows...
BCA0 Header (0x10 bytes)
- Section Offsets (since there is only one section, this is only a single 4 byte offset)
- JNT0 Section (contains 3 sub sections which are present in both NSBMD and NSBTX files, namely UNKNOWN, DATA, NAMES)
------------------------------------------
Following this each animation jumps to its own section that begins with a J_AC (0x4A004143) magic stamp.
Each J_AC store the initial settings for each animation as well as points to places in the latter part of the file relative to the start of the J_AC. The offsets for every J_AC point to the same two places in the file.
kiwi.ds only got as far as the J_AC sections, which I figure is because they have a really weird way storing information.
For each object in a J_AC section, it seems to hold the base settings for Translation, Rotation and Scaling, as well as the Object # and a currently unknown byte (which always seems to be zero).
The settings a referenced using a 2 byte flag which is as follows...
xxZYXBSCxRZYXBTx
if T, R, or S equal to 0, data is present for each of their corresponding types (ie Translate, Rotation, Scale).
Both T and S control the following 4 bits to their left, being B, X, Y, Z.
R controls C.
if the corresponding flag equals to 1 a DWORD follows (except for Scale XYZ which use two DWORDs).
otherwise two WORDs and a DWORD follow.
This is how I've interpreted the data, which seems to fill in all the blanks in kiwi.ds's code, and so far has all data that follows the flag present and accounted for. So now I just have to figure out what the hell it all does :p
This isn't a very good explanation, but hopefully it sheds some light on the currently unknown NSBCA file :p
More to come once I figure that out.
[edit 4]
Animations are a pain.
When a flag is set, the data that follows are the values that don't change throughout the animation, essentially if say a character is walking to the left, the Y value may remain constant for the whole animation. But when it's not set, 8 bytes follow which reference to what happens for each frame in the animation. Breaking it down, the first two bytes always seem to be zero, and the last four bytes are an offset relative to the start of the J_AC section, which seem to always point to somewhere after the second offset found in the J_AC header.
The first offset section is made up of 6 byte chunks, the first two bytes are some kind of id or number and the last 4 bytes make up two word size signed values or a single signed dword. So I figure this is some kind of matrix table.
The second offset section seems to hold a variety of different data. Most often the first chunk seems to hold multiple two byte chunks, the first byte incrementing by 1, but this varies.
The problem I am having is that there doesn't seem to be a constant size for data referenced from the second section. Assuming references don't overlap, it seems that the third byte in the above mentioned reference data specifies how the data is stored, and more importantly right now...how big it is.
Say the animation is 30 frames and the Translation X value changes throughout it? So assuming the first section is the matrix table, you would need at least 30 bytes to properly reference which matrix from the table needs to be loaded into the current matrix. However I've seen data which which is 32 bytes, or even less than 30 bytes which is somehow meant to represent the entire 30 frames for that particular variable. Then there's also the possibility that the CAN be a zero sized first section as well (meaning there is no matrix table). There's at least 7 different types which so far have made no sense to me at all
So like I said, animations are a pain, but I'll figure it out eventually
Topic: The Console Tool (by Low Lines) (Read 250836 times)