CloudMax's N64 Texture Packer [v2.3 released]

[CloudMax]

Version 2.3 has now been released. You can use it online or download it at http://cloudmodding.com/app/texturepacker

You can also download it here on the-gcn at https://www.the-gcn.com/files/file/69-cloudmaxs-n64-texture-packer/

Keep in mind that releases are delayed on the-gcn from now on. Reason for this is so that I can make necessary hotfixes to issues that may pop up right after a new version is released. Things hosted on my site can swiftly and quietly be updated to resolve the issues, but the same is not possible here. If no problems are detected within a day or two, I'll most likely upload it here. If a problem is found, I may decide to delay the release further, or wait until I release the next version.

 

The N64 Texture Packer is a tool that I started working on quite recently. (It is written in javascript and will run in your browser)

It was initially supposed to be a tool packed with my z64editor, it even runs on an updated, slightly modified, version of the javascript that handles all the texture importing/exporting of the editor among other things.

The tool quickly evolved and became a standalone tool that supports any decompressed N64 ROM rather than being exclusive to OoT.

Basically this tool will be a new way of creating and sharing texture packs, similar to that of a Rice's Video Plugin pack.

There is however a few key differences, some good, some bad.

First of all, this tool is designed to be hardware compatible. Rather than relying on an emulator plugin, the tool will import the texture pack directly into the ROM.

This poses a problem, how will the tool know where to import the textures? Well, it doesn't, so you have to tell it where to import the textures by providing the address it is located at.

So unlike a Rice's Video Plugin texture pack where it dumps the textures for you, and you just modify the texture and be done with it, with this tool you'd have to look up the location of each texture.

The easiest way to do this (that I am aware of) would be to dump the textures using Rice's Video Plugin, then convert the textures to texture data using for example SoD's converters and search for the data in the ROM.

 

Now for the actual format that the texture pack will use. I've reworked it several times, and I'm happy with the current format.

The texture pack is a .zip archive. It will contain a directory named "pack", which is where the actual texture pack is located. Anything can be placed outside the pack directory, such as an instruction text file, the tool, etc.

 

Within the "pack" directory you'll find a set of folders (or just one folder). Each folder represent an offset within the ROM you're making the pack for.

The folder name decides the offset, and it can be set up in two different ways. The format is [type]_[hex address]_[description]

Type A: the textures within the folder will be imported relative to the specified hex address.

Type P: the textures within the folder will be imported relative to the 32bit value at the specified hex address.

The description is optional and can be used to describe what the folder points toward, etc.

Examples: texture_pack.zip/pack/A_007D6000/ and texture_pack.zip/pack/P_00012FF0_icon_item_24_static/

Textures located in the first folder would be imported into the ROM relative to address 0x007D6000

Textures located in the 2nd folder would be imported into the ROM relative to the 32bit value located at 0x00012FF0 in the ROM

Now, in the OoT MQ Debug ROM, 0x007D600 is the start offset of icon_item_24_static. And 0x00012FF0 is the dma table entry which points to 0x007D6000. So both folders point to the same location.

Since the 2nd folder uses the dma table, it will point correctly even if files have been shortened or extended before it, as it uses the dma table rather than a static address.

This will prove useful if you want your pack to be compatible with ROM Hacks, etc., where a static address may point incorrectly.

 

And now the textures. The textures are .png files located within the folders mentioned above, and the names are formated [hex address]_[texture type]_[description].png

The hex address is the address the texture should be imported to, relative to the offset of the folder it is placed in.

The texture type tells the tool what format the texture should be imported in. The available formats are i4, ia4, i8, ia8, rgba32 and rgb5a1.

And again, the description is optional. It can be used to describe what the texture is used for, etc.

Example: texture_pack.zip/pack/P_00012FF0_icon_item_24_static/00000900_rgba32_fire_medallion.png

Following the previous example, this would import the image as an rgba32 texture at 0x00000900 relative to 0x007D6000, which is 0x007D6900.

And if you were to remove the descriptions in the names, the path would be texture_pack.zip/pack/P_00012FF0/00000900_rgba32.png

 

The length of the hex addresses must not be 8 characters, and folder/file names are case insensitive. I only type it that way for consistency.

 

This may seem like a lot to take in at first, but it really isn't that much at all. It is a very simple format that anyone should be able to grasp almost instantly.

 

NOTE: Due to browser limitations, textures will be slightly modified when imported into the ROM. This should not be noticeable at all, and is something that happens to all images that are loaded into a web browser.

You will however notice that when you import a clean texture dump into the ROM, the hex won't be the same due to minor color differences.

[Jason777]

So, unlike Rice's, this tool will not work for hi resolution images in order to stay hardware compatible?

[CloudMax]

So, unlike Rice's, this tool will not work for hi resolution images in order to stay hardware compatible?

That is correct.

[HeavyZ]

So, unlike Rice's, this tool will not work for hi resolution images in order to stay hardware compatible?

Marshal who made the N64 Drive is supposed to still be working on the N64 to HDMI board. I haven't been keeping up to date on that though, so for all I know he could have finished it, or put it on hiatus. In the meanwhile there's the RGB mod for Pal N64's, which is not a problem it being pal if you modify the spot where the cart fits in, or you could just get an N64 Drive, or ED64 with a Pal shell.

I think I'm gonna wait for that HDMI board though lol

[Arcaith]

The HDMI board won't allow you to use higher resolution textures, it just modifies the output resolution of the N64's video signal to stop the crappy artifacts you get when running it through composite cables on larger TVs.

[john_smith_account]

We need more tools like this!  Good work, I look forward to seeing the finished product.

[HeavyZ]

The HDMI board won't allow you to use higher resolution textures, it just modifies the output resolution of the N64's video signal to stop the crappy artifacts you get when running it through composite cables on larger TVs.

I'm not that noobie. I'm just saying it will look good on hardware on either CRCT TV's or HD ones once that is released. We have HD texture packs for emulator. And really if we really are worried about resolution, and graphics that much then I don't see why we don't hack, and document twilight princess more.

[CloudMax]

1.0 is now out and available for download. It can also be accessed online on my website.

Check the top of the first post for links.

[john_smith_account]

Get it, got it, *WILL* use it!

 

Many Thanks!!!

[!Tommy]

I'm having some issues trying to get the tool to rip the textures. So correct me if I'm doing something wrong.

 

Now, first off, do I *have* to use IE10? I don't really have easy access to a computer with it so I tried this with the latest Firefox and somewhat recent Chrome browser. When I drop the ROM in the site either online or locally downloaded, I get a zip file that says texture pack but it has a small instructions text file and nothing more. I've read the instructions several times and I don't know if I'm doing something wrong or if it's my browser that's causing the issues.

[CloudMax]

I'm having some issues trying to get the tool to rip the textures. So correct me if I'm doing something wrong.

 

Now, first off, do I *have* to use IE10? I don't really have easy access to a computer with it so I tried this with the latest Firefox and somewhat recent Chrome browser. When I drop the ROM in the site either online or locally downloaded, I get a zip file that says texture pack but it has a small instructions text file and nothing more. I've read the instructions several times and I don't know if I'm doing something wrong or if it's my browser that's causing the issues.

Latest version of Firefox, Chrome, Safari, Opera and Internet Explorer SHOULD work. I tried all except Safari, but I don't see why it wouldn't work.

When you generate the new pack, the .zip file should contain a folder named "pack" along with the instructions txt file.

The pack folder should *always* be there. Even if you provide a file that isn't a ROM to begin with. It should just treat it as an unknown ROM in that case and generate a .zip containing a /pack/A_00000000/ folder.

 

the instructions txt file is for the person you share the pack with once it's done, rather than you, so that they get some kind of pointer on what to do with it.

 

There could possibly be some error causing the pack folder from not getting included in the zip file for you.

But if that was the case, the site should just freeze and not download at all, because the tool does not catch any errors.

[!Tommy]

Latest version of Firefox, Chrome, Safari, Opera and Internet Explorer SHOULD work. I tried all except Safari, but I don't see why it wouldn't work.

When you generate the new pack, the .zip file should contain a folder named "pack" along with the instructions txt file.

The pack folder should *always* be there. Even if you provide a file that isn't a ROM to begin with. It should just treat it as an unknown ROM in that case and generate a .zip containing a /pack/A_00000000/ folder.

 

the instructions txt file is for the person you share the pack with once it's done, rather than you, so that they get some kind of pointer on what to do with it.

 

There could possibly be some error causing the pack folder from not getting included in the zip file for you.

But if that was the case, the site should just freeze and not download at all, because the tool does not catch any errors.

I tried the process again and I opened it up in WinRAR instead of WinZIP, I now see a pack folder and it's just like how you outlined which is kind of odd. Now for a question. Does the tool actually rip the textures at all or does it just import them once you rip them using an external source and edit them? I used a clean debug ROM for the process too so there shouldn't be any sort of weird errors. However, I would like to know if the tool rips any textures at all or if I'm on my own with that part. I apologize that I'm a bit slow at this. Usually once something is explained a little more thoroughly, I catch on.

[CloudMax]

I tried the process again and I opened it up in WinRAR instead of WinZIP, I now see a pack folder and it's just like how you outlined which is kind of odd. Now for a question. Does the tool actually rip the textures at all or does it just import them once you rip them using an external source and edit them? I used a clean debug ROM for the process too so there shouldn't be any sort of weird errors. However, I would like to know if the tool rips any textures at all or if I'm on my own with that part. I apologize that I'm a bit slow at this. Usually once something is explained a little more thoroughly, I catch on.

It is able to extract textures that i have manually told it to extract by providing texture offsets, types and sizes.

This should work with a clean Debug ROM. (I think. It could just be that the ROM I'm using as a base isn't clean.)

I set it up so that it check the ROM ID and version in the ROM header to see which ROM it is that you're providing.

If you open the javascript console in your browser (Ctrl+Shift+J in chrome) it should say "ID: NZLE, Ver: 15" when you drop the debug ROM on the site.

[!Tommy]

Does this look right to you?

 

event.returnValue is deprecated. Please use the standard event.preventDefault() instead. jquery.js:5374

ID: CZLE, Ver: 15 texturepacker.js:180

JSZip {files: Object, root: "", load: function, filter: function, file: function…}

1. files: Object
2. root: ""
3. __proto__: Object

 

It still downloads an empty texture pack though. It has the folders when I open in WinRAR along with the instructions txt file but nothing else ever downloads with it or inside of it except those items and it doesn't matter if I use Chrome or Firefox, it's always the same situation.

[CloudMax]

Oh. Your ROM does not have the same ID as mine. Your says CZLE for the ROM ID. Mine is NZLE.

So if doesn't detect the ROM as the OoT MQ Debug, and therefor does not extract any textures.

 

If anyone know why this is, that'd be great. I guess I could make it check for either IDs in future versions. Until then I guess you'll have to either find a debug rom that works, or change the ID manaully in the ROM header. (you can easily locate it in a hex editor)

[!Tommy]

Oh. Your ROM does not have the same ID as mine. Your says CZLE for the ROM ID. Mine is NZLE.

So if doesn't detect the ROM as the OoT MQ Debug, and therefor does not extract any textures.

 

If anyone know why this is, that'd be great. I guess I could make it check for either IDs in future versions. Until then I guess you'll have to either find a debug rom that works, or change the ID manaully in the ROM header. (you can easily locate it in a hex editor)

Oh my gosh, I didn't even see that difference!! I changed it via hex editor to NZLE and now it finally works! I finally have textures ripped! Thanks so much, CloudMax!

[CloudMax]

Version 1.1 is now released.

You can use it online or download it at http://cloudmodding.com/n64/

 

Changelog:

• Deflate compressed files are now supported.
• .jpeg/.jpg and .bmp/.dib images are now supported.
• The tool will no longer crash if you attempt to import an empty texture pack.
• If an error occurs, such as the one specified above, you'll now receive a message.
• Large files will no longer cause the tool to freeze temporarily when importing a pack.
• Rewrote the texture pack import code to improve performance and make import bar reliable.
• Solved an issue that caused the tool to get stuck in an import state if a file was invalid.
• You can no longer generate or import a pack when the tool is already doing so.
• The import bar is now properly reset after importing a texture pack.
• Updated a dead link in the instructions.txt file.
• All buttons can now be properly selected with Tab.
• All links now open a new tab.

[!Tommy]

I have a question, CloudMax. Are we able to use textures ripped using Rice to be able to import into OoT using your tool? I want to use a few MM textures and I get mixed results depending on the situation. And yes, I made sure I renamed the files accordingly so that shouldn't be an issue there. However, sometimes it seems to upload just fine and redownload the ROM but the change doesn't take effect. Sometimes it shows up as an empty download where it'll download a 0 byte ROM file. And now I'm to where it won't even finish uploading and gets stuck at a file I never even touched. So let me ask, is ripping textures via Rice to reupload not allowed with this tool?

[CloudMax]

That is very odd. If the names are set up correctly it *should* work just fine. I am using the tool to import all the custom textures I'm using for my mod, and I've applied it like 50-60 times with the latest version.

If you send me the pack I can see if I can find the problem.

Also, are you using a downloaded copy of the tool, or are you using it online?

 

Edit:

As an example, I just threw together a pack and applied it with the latest version of the tool, and here's the result:

 

 

So it works perfectly fine for me.

 

Edit2:

Sorry about that! It appears that there was an issue with the IA8 and RGB5A1 converters, which made the arraybuffer half the size of what it should've been, so it caused an overflow and crashed.

I'll be uploading a new version shortly with various bug fixes.

 

Edit3:

Version 1.2 is now released.

• The tool will no longer crash when importing ia8 and rgb5a1 textures.
• Solved an issue that caused the tool to get stuck in a loop if provided with 2 ROMs or 2 Packs.
• Fixed several crashes that could occur if you provided various files in specific orders.
• You must now provide a N64 ROM in order to generate a new texture pack.

Edited January 25, 2014 by CloudMax

[!Tommy]

I finally got it working! I ended up using the offline editor as the online one seemed to run into problems. However, it seems Firefox is having issues (at least mine is) for ripping textures, it just does nothing at all. Chrome works fine for ripping textures. It also seems like if there's already a 'combined' ROM in the downloads folder, it seems like the changes don't take effect. However using the tool offline with Chrome, I seemed to have perfect results, even using the Rice ripped textures. Are you ever going to define more image addresses within the tool to rip even more textures as you find them so they'll be downloaded when we drop the ROM in the tool to create new texture packs?

[CloudMax]

I finally got it working! I ended up using the offline editor as the online one seemed to run into problems. However, it seems Firefox is having issues (at least mine is) for ripping textures, it just does nothing at all. Chrome works fine for ripping textures. It also seems like if there's already a 'combined' ROM in the downloads folder, it seems like the changes don't take effect. However using the tool offline with Chrome, I seemed to have perfect results, even using the Rice ripped textures. Are you ever going to define more image addresses within the tool to rip even more textures as you find them so they'll be downloaded when we drop the ROM in the tool to create new texture packs?

The online and offline version should both work properly, however, the website may be cached as I do not provide a version stamp on the urls, so it is possible that it is loading old versions of files, causing some issues.

I'll fix that for the next version so that the online and offline version should work the same way.

I looked into the firefox issue, and you're right. One of the last minute changes seems to have broken firefox. The funny thing is, it is firefox that actually works correctly. the program SHOULD crash. I placed a function within the code that runs when combining files, but I also call the function from the code that generate a texture pack. In other words, I'm calling a function that shouldn't even be defined, I'm surprised it works in chrome.

So until the next version is out, use chrome.

And about the issue about changes not taking place in the downloads folder, I've never had the issue because my browser automatically suffix the file with (1), (2), etc. if there's already a ROM in the downloads folder.

That does not seem to be the case for all browsers. I'll have the tool add a small timestamp in the next release so that this won't happen.

 

And yes, I plan to add more addresses later. At the moment it uses the list from my z64editor. There'll most likely be a bunch of new textures in 1.3 (some stuff from the title screen, item names, action texts)

 

Edit:

Scrap the whole 1.3 idea.

I've worked on the tool all day and improved a lot of things, and will be releasing 2.0 today.

With this release, texture packs that are downloaded will contain proper names for almost every single texture available in the pack (and will have for all of them at some point).

Here's a quick example: https://dl.dropboxusercontent.com/u/6440063/OoT/modding/texture_packer_2_preview.png

Now, there will also be one major new feature for 2.0, which is why I decided not to go with 1.3, and that is the "generators".

The generators is what tells the tool where all textures it should download for the provided ROM are located, their sizes, formats, and even a name to go along with it.

Previously it was setup in a very lazy and bad way, there really wasn't a way to extend it and add new functionality.

Now there will be a "generator" for every ROM that you can generate texture packs for. Now, I will only be maintaining the OoT Debug ROM generator, but the main idea of this feature is that others are able to create their own generators for other games and share it with others, so that they can create their own packs for other games.

 

The setup is quite simple. There is one script file containing an object with one entry for each ROM. the entry key is the ID and Version of the ROM in question, and that's how the ROM will detect which generator to use, and the value of the entry is the name of the generator that is to be used.

Here's what it looks like by default:

generatorEntries = {
	"NZLE15":"oot_debug_gen",
	"CZLE15":"oot_debug_gen"
}

Now, as CZLE15 and NZLE15 (both of which are found in different OoT Debug ROM) both are "oot_debug_gen", we'll create a file named oot_debug_gen.js

Now, the format for the generator is *slightly* more complicated, but still relatively simple, and anyone should be able to understand it quite easily.

 

 

generators["<name of this file>"] = [
	"<folder name>":{
		type:<address or pointer>,
		address:<address of the folder>,
		textures:{
			<texture address relative to folder>:{size:[<texture width>,<texture height>],format:"<texture format>",name:"<texture name>"},
			...
		}
	},
	...
];

 

Here's an example:

 

 

generators["oot_debug_gen"] = {
	"icon_item_static":{
		type:pointer,
		address:0x12FE0,
		textures:{
			0x5A000:{size:[48,48],format:"ia4",name:"Heart Piece 1"},
		}
	}
};

 

This example would produce a pack that looked like this:

pack/P_00012FE0_icon_item_static/0005A000_ia4_Heart_Piece_1.png

 

All symbols in the folder and file names which are not supported will be replaced with a hyphen. Spaces will be replaced by underscores.

 

So if you have textures that you want to extract from the ROM, but aren't available in the generator already, you can add it in yourself without any trouble.

 

Iif anyone wants to contribute with textures that aren't already available in the generator, feel free to send me the details of the texture in question. I need the name of the file the texture is located in, the offset of the texture within the file, the format of the texture, and the size of it. If you do not know the format I can look it up myself.

 

And if someone starts developing generators for other games I'll gladly include it with the official release of the tool if it looks promising enough.

 

Edit2:

Version 2.0 is now released.

• Solved an issue that caused some browsers to crash when attempting to generate a pack.
• When using the tool online you'll no longer have issues with previous versions being cached.
• The tool no longer get stuck in the loading state when providing an invalid file.
• The tool will no longer crash when using any symbol except underscore in pack file names.
• Generated packs will only include the A_00000000_default folder if the pack is empty.
• Texture Packs and ROMs that are generated now have a timestamp in the file name.
• The OoT MQ Debug ROM pack now include title screen, item names and action texts textures.
• A new feature called "Generators" has now been implemented. The generators is what tells the tool where textures are located so that they can be extracted from the ROM. You're able to add new ones for other games, or modify existing ones. There is a brief explanation of how it is set up in the generators/generators.js and generators/oot_debug_gen.js files.

[!Tommy]

I think Firefox handles caching a bit differently because my packs will not upload into the ROM (even though it appears to!) with it but the same packs will upload in Chrome so I don't know what's up with that. I'm having a few very minor ill effects when using the latest texture packs such as some of the text on the file select screen becomes transparent instead of white and some of the item names in the start menu look a little choppy but it's not the biggest deal at all. It's just the only thing I've noticed so far with it.

[CloudMax]

That is.. odd..

I just tested writing a clean texture pack back onto a clean ROM... And a lot of textures are all messed up. I do not know what has happened, for some reason I4 and IA8 textures are all messed up.

I have no idea how this could possibly have happened. I have not touched the convertors.. I think..?

I'll look into it.

 

Edit:

I've been doing it wrooong.

What I've been calling IA4 textures all along is actually IA8 textures. I have no idea how I missed this since my "IA4" textures actually use 8bits.

And what I've been calling IA8 textures have been IA16 textures that use 16bits.

Now.. this leaves us with only IA8 and IA16..? Where the hell is IA4?!

Well, turns out that I'm dumb. IA4 is a format that I didn't know about which uses 4bits. (logic...) 3 bits are used for grayscale, and one bit is used for alpha.

 

So I've been calling I4 and IA4 textures that same thing, which explains the chaos.

 

Edit2:

I found the problem with the IA16 textures. (what caused the file select to look all messed up, etc.) The alpha and the color had swapped places.

 

Edit3:

Version 2.1 is now released.

I've tested every single texture format now, and every texture available in the generator. If something is wrong now I'm going to be sad.

Changelog:

• IA16 was incorrectly named IA8, this has been corrected.
• IA8 was incorrectly named IA4, this has been corrected.
• IA4 (the real IA4 format) is now supported.
• All textures in the OoT Debug Generator that were incorrectly set to I4 has been corrected.
• Solved an issue that caused the gray and alpha channel to swap place in IA16 textures.

Edited January 27, 2014 by CloudMax

[CloudMax]

Version 2.2 is now released.

An issue was solved that caused some textures to not download when generating a new pack.

It includes over 100 additional textures.

All File Select textures are now downloaded when generating a pack. This includes all the unused textures found in the title_static file.

I also added all the textures from message_static and map_name_static. In other words, the 4 dialog box textures, the triangle, square & arrow buttons used for the dialogs, and the map title cards, as well as the world map area names.

I've now given names to the do_action_static textures, instead of just calling them "action_1, action_2, ...".

 

You can use it online on my website as usual, or download it from there. It will most likely be available on the-gcn tomorrow.

[ASAP Sam Worldwide]

This is a great tool. Thanks for creating it!