SB64 Level Texture Editor Tool - TSBT

[mib_f8sm9c]

Tingle's Smash Bros Tuner (TSBT) is a project that SoundBlitz and I are working on to provide an editor for various aspects of the SB64 rom. While we're still analyzing what can be feasibly done, our current goal is to allow for level importing/editing.

For now though, we have this Level Texture Editor tool! Essentially this is an experimental beta tool to be used to replace the textures of levels. Just to be clear, there may still be some bugs and imperfections in the program. Always be sure to keep a backup of your rom!

Right now it's pretty limited, it can only edit textures for Hyrule Temple, but we should be able to expand it out to the rest of the levels fairly soon. For an example of what it can do, here's something I cooked up in a half hour to turn Hyrule Temple into Bowser's Castle:

Full Album

Links:

TSBT Texture Editor v.0.1:
https://drive.google.com/file/d/0ByMgk_gq9ClkRHhNTW1yUTh1UEU/view?usp=sharing

Source code:
https://github.com/mib-f8sm9c/TinglesSmashBrosTuner

Credits to Parasyte for the CRC fixing code, CaitSith2 for nvpktool, Zoinkity for info on filetables/fixing references when resizing the rom


Usage:
First off, it's important to note that you MUST USE A NON-BYTESWAPPED USA VERSION OF THE ROM. Currently that is the only supported format. You can check the byteswap by opening the rom with your favorite hex editor. If the text representation at the start of the rom data reads "SMASH BROTHERS", then you're good to go. If the letters are mixed up, like "MSSA HRBTOEHSR", then you need to un-byteswap your ROM. Tool64 is my preferred tool for doing this (I think they call the un-byteswap version "Big Endian", or more accurately I call the Big Endian version "un-byteswapped" : P )

After that, it should be simple. Load the rom, then select your level (only Hyrule Temple for now), load the level, and you should be able to export/import textures. After doing what you want, then you save the level and then save the ROM, and it should be good to go.

An important note: You will probably see a decrease in texture quality when importing. This is because most textures are in a very low-quality format to save space. Each texture (at least in Hyrule Temple) only contains 16 distinct colors. This can probably be fixed in the future, but for now it's part of the process.

Also, make sure to only import the same size image as the one you're replacing. I forgot to bugtest that, so I don't know what will happen, but I doubt it'll be good.

Current dev plans for this beta tool:
-------------------------------------

v.0.1 - Released today!
-Single level only (Hyrule Temple)
-Limited ROM format (USA, non-byteswapped)
-Textures are flipped vertically (slight oversight on n64 texure formatting)
-Can only import to same image format (loss of image quality)
-Background images can seemingly get damaged by the tool?

v.0.2 - Release in 1-2 weeks
-All levels (hopefully!)
-More ROM formats (at least allow for byteswapped format)
-Fix the texture flipping
-Still only import to same image format
-Try to fix the background image issue

v.0.3 - Evaluate if needs to be released
-Catch up to missed goals for v.0.2 / bugfixes
-Allow for hi-res image importing
-Other improvements not yet considered


While this is a first step in the direction of having fully custom levels, it's pretty promising. Since Zoinkity wrote some code to fix hard-coded references to allow resources files to change file size, it should be feasible to allow adding completely new data to the files. However, there's a lot we still don't know, and an actual level editor is still a ways off. But we hope that this texture editor will at least be a good start to getting some actual modding tools for SB64.

 

[Cyjorg]

This is great! I have a few questions.

private int[] HyrulePaletteLocations = { 0x8, 0x838, 0xC68, 0xE98, 0x16C8, 0x1AF8, 0x1D28, 0x2558, 0x2788, 0x2838, 0x2A68, 0x2C98, 0x2EC8 };

private int[] HyruleTextureLocations = { 0x30, 0x860, 0xC90, 0xEC0, 0x16F0, 0x1B20, 0x1D50, 0x2580, 0x27B0, 0x2860, 0x2A90, 0x2CC0, 0x2EF0 };

1. Does this mean you're still locating the textures yourself?
2. Is there any chance you could explain the format for CI textures (the only one I could never figure out) or at least point me towards some sort of documentation?

 

[mib_f8sm9c]

Yep! I have some code that will render F3DZEX microcode that I just run the data through, but I save any texture and palette locations in the data. So the next few days I expect I'll be locating each stage file and then running it through the same process, spitting out a bunch of texture and palette locations, and I'll mark them down again.

CI format is pretty simple! I actually like it a lot, although it is a bit more of a headache than something like RGBA. The idea is that you store a palette of colors somewhere outside the image, and then the texture stores references to these palette colors rather than actual color values. It really cuts down on image sizes, though quality isn't always the greatest.

There's 2 types of CI format for the N64: CI4 and CI8. Each one specifies the size in bits of the pixel (hence CI4 is 4 bit pixels, CI8 is 8 bit pixels). This means that in CI4, each pixel can be one of 16 colors, and CI8 it can be one of 256 colors. And from what I understand, the palette is stored as RGBA in 5551 format. (Also note that CI4 forces the palette to be 16 colors, and CI8 256 colors)

From what I've seen so far, almost every single texture has been CI4, but it looks like there are some exceptions. Below is a pic of an example of a CI texture/palette combo as it tends to be stored in the ROM.

So let's finish off this example. We have a CI4 texture here, the palette contains 16 colors indexed 0-15. If we look at the first byte, 0x02, that means that the first pixel will be the 0th (base zero) color (which is 0x5295 in 5551 RGBA format), and the second pixel will be the 2nd (0x6B5B). And so on and so on until you read the whole texture.

 

[Cyjorg]

Yep! I have some code that will render F3DZEX microcode that I just run the data through, but I save any texture and palette locations in the data. So the next few days I expect I'll be locating each stage file and then running it through the same process, spitting out a bunch of texture and palette locations, and I'll mark them down again.

CI format is pretty simple! I actually like it a lot, although it is a bit more of a headache than something like RGBA. The idea is that you store a palette of colors somewhere outside the image, and then the texture stores references to these palette colors rather than actual color values. It really cuts down on image sizes, though quality isn't always the greatest.

There's 2 types of CI format for the N64: CI4 and CI8. Each one specifies the size in bits of the pixel (hence CI4 is 4 bit pixels, CI8 is 8 bit pixels). This means that in CI4, each pixel can be one of 16 colors, and CI8 it can be one of 256 colors. And from what I understand, the palette is stored as RGBA in 5551 format. (Also note that CI4 forces the palette to be 16 colors, and CI8 256 colors)

From what I've seen so far, almost every single texture has been CI4, but it looks like there are some exceptions. Below is a pic of an example of a CI texture/palette combo as it tends to be stored in the ROM.

So let's finish off this example. We have a CI4 texture here, the palette contains 16 colors indexed 0-15. If we look at the first byte, 0x02, that means that the first pixel will be the 0th (base zero) color (which is 0x5295 in 5551 RGBA format), and the second pixel will be the 2nd (0x6B5B). And so on and so on until you read the whole texture.

I can locate every stage file for you. I know I have Deeamland and BF mapped already. Others shouldn't be hard at all

 

[mib_f8sm9c]

Sure : ) I've only found the level for Saffron City and strangely enough 2 copies (?) of Battlefield so far. If you just give me the start offset of the vpk0 block for the level (ex. Hyrule Temple vpk0 header was at 0x40BDCA, vpk0 data at 0x40BDD4), that'd help me out a great deal. I still have to go in by hand and locate all the F3DZEX blocks, but that's the easy part.

 

[tehz]

Great work so far!

Weird that the pallet for that image is before the pixel data. I've only seen the pallet(s) after the texture data in the images I've looked at so far. Another thing to keep in mind I guess. Is there still the "footer" that lists the sizes/offsets/formats after the texture data?

 

[mib_f8sm9c]

Footer? I've never seen any of that. That info is stored in the F3DZEX microcode, which comes after the texture data and vertex data usually. Is that the footer you're talking about? It looks like this:

 

[tehz]

Hmm, it doesn't really look like that, and nothing on the F3DZEX wiki page looks familiar either. (not that I have any idea about ucode or even 3D modeling).

Thinking about it know, I've probably only been looking at simple sprites. (Eg, the stage icons in your first image). So, it's not too surprising if it were different. I don't remember the "footer" format off the top of my head, but it went something like this:

0x00 4 Bytes  Width in Pixels for image data starting at 0x0C
0x04 4 Bytes  Height in Pixels ...
0x08 4 Bytes  Blank
0x0C 2 Bytes  Relative offset in bytes to Image data described by 0x00 and 0x04
0x0E 2 Bytes  Relative offset in bytes to next relative offset
[This set can repeat any number of times depending on how big the image is, probably.]
[Each set is a chunk of the same image]
If 0x0E+4 is blank
0x10  4 Bytes  blank
0x14  4 Bytes  Full Image Width
0x1C 4 Bytes  Full Image Height
....
so on

Have you seen/encountered a format like this before?

strangely enough 2 copies (?) of Battlefield so far.

This is really cool. I wonder how the stage data are indexed to their index numbers...
Also, do you know if there are two stage models (one for the stage itself, and one for the stage select screen), or only one?

 

[mib_f8sm9c]

Nope! But I've been only messing around with smash bros for a couple weeks or so, and only with F3DZEX stuff for the levels, so there's still a lot I haven't seen before. My specialty (or at least what I've developed a good sense for) is the 3d model info in n64 roms, so that's what I'll stick to for now.

 

[mib_f8sm9c]

Thought I'd pop back in on this, since it's past the date I said I'd release something more. The delay is a combination of real life kicking me in the teeth (as always) and having a difficult time finding the correct resource files in the ROM. I've found models for Saffron City, Battlefield and Final Destination, but the rest of what I've been looking at has just been stuff life platforms and minigame visuals. The file table which contains references to the model resources for levels/objects also has a reference to a single part of the model, so I should be able to use that to quickly id files and hopefully speed up the process.

 

[Danny_SsB]

I have some stages files of textures and colissions localization if you need help

 

[mib_f8sm9c]

Yeah, I would like some help : ) Can you give me the offset in the ROM file of textures in the levels I haven't found yet? Even with a single offset I'd be able to find the block of model data for that level, and it wouldn't be hard to work from there.

Also, where is the collision data stored? And do you know how it's stored?

 

[Cyjorg]

NEVERMIND CS IS C#