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

[john_smith_account]

Can't get it to save my logo.  It generates the new ROM and acts like it's working, then magiclly it reverts back.  I don't even know where's it's pulling the old logo texture from at this point.  *shrugs*

 

P.S.  

 

I'm not one to try a tool once and dis it.  I'm not sure what I'm doing wrong here.  I select the ROM and pack.zip at the same time...drop em and it generates the new ROM.

 

I thought maybe I was suppose to do them one at a time, but when I drag pack.zip first by it's self, I get an error message telling me it's not and n64 rom.

 

Extraction works fine though.

 

 

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.

 

Crap, I didn't read close enough!

[CloudMax]

Oh crap. I totally forgot about the Firefox issue. So the tool even has the false statement saying that it does work in firefox.

Truth is, I only *fully* test the tool in chrome. Reason is because I use the tool every time I recombine my mod, and since chrome is my main browser, I use that for it.

When I test the other browsers, I only make sure that no errors appear, and that a new file is generated and downloaded, I do not usually try them out.

However, it seems to be a firefox exclusive issue, I will look into it later (possibly today) and see if I can solve the problem, as it is quite a serious one.

This *should* be the only issue with the tool. I am not aware of any other, since I've resolved the issues related to the convertors I've written.

Well, I am certain that there are other ways to cause the tool to throw exceptions, but as long as you do what you're supposed to (do not attempt to write past the boundary of a file, provide properly named files in the packs, etc.), that shouldn't be a problem.

[â–²ChriisTiianâ–²]

CloudMax, this is not working for me.

When i drop the ROM in the page, it extract the textures.

But when i drop the ROM and the ZIP file, this download a new ROM and it doesn't have the new textures.

I'm using Chrome, can you help me?

[CloudMax]

I have no idea at all how that can possibly happen. It works perfectly for me. And it worked on my laptop as well, so it's not like it's my computer that makes it magically work.

I tried generating a new pack, changing one single texture, and then applying the pack again, and it sure did work for me. I've never had a problem with it in chrome.

I just tried my local version, the online version, the offline version. I've applied 2 different packs to two different ROMs, they all worked perfectly.

It's so weird that these issues happen.. because the tool is basically extracting and importing stuff the same way.. except in reverse... Why would it be able to extract but not import?

 

The only thing I can think of is that you use some very old version of chrome or something, but shouldn't it cause an error if that's the case..

Another issue would be if you moved the files in the .zip pack or something. you have to place the texture folders within the /pack folder in the zip, and you can't place the files outside of the folders they were in originally, unless you create a new folder that points correctly.

And you obviously have to keep the first 2 arguments in the texture filenames, or the tool won't have a clue as to where it is supposed to import the texture and just skip it.

[â–²ChriisTiianâ–²]

I have no idea at all how that can possibly happen. It works perfectly for me. And it worked on my laptop as well, so it's not like it's my computer that makes it magically work.

I tried generating a new pack, changing one single texture, and then applying the pack again, and it sure did work for me. I've never had a problem with it in chrome.

I just tried my local version, the online version, the offline version. I've applied 2 different packs to two different ROMs, they all worked perfectly.

It's so weird that these issues happen.. because the tool is basically extracting and importing stuff the same way.. except in reverse... Why would it be able to extract but not import?

 

The only thing I can think of is that you use some very old version of chrome or something, but shouldn't it cause an error if that's the case..

Another issue would be if you moved the files in the .zip pack or something. you have to place the texture folders within the /pack folder in the zip, and you can't place the files outside of the folders they were in originally, unless you create a new folder that points correctly.

And you obviously have to keep the first 2 arguments in the texture filenames, or the tool won't have a clue as to where it is supposed to import the texture and just skip it.

 

This is the .zip file: http://www.multiupload.nl/NX6EVFXWN2

And for the ROM, i'm using a default ZELOOTMA.z64, i have no idea why this happen. :/

I drop the ROM & the .ZIP file, all correct, and the page download a new ROM, but it doesn't have the texture imported. :/

 

EDIT: Tested with offline version, and doesn't work

[CloudMax]

It sure works for me. No problem at all. (put it over my mods ROM though, as I already had it right in front of me)

So I guess that rules out there being a problem with the pack itself. It's either the ROM (I'm pretty sure this is not the case), or the browser (seems likely considering other have had the same problem with firefox).

I am really starting to wonder why the textures aren't applied. Like.. this shouldn't be possible.. The ROM is provided and stored in a variable.

This variable is being edited, and after a texture has been imported, it moves onto the next texture.. When all textures are added, the very same variable stored when dropping the files are used to then download the new ROM.

So, the only possibility is that for some unknown reason, some browsers do not apply any changes at all, which is very, very, odd.

[â–²ChriisTiianâ–²]

So, the only possibility is that for some unknown reason, some browsers do not apply any changes at all, which is very, very, odd.

 

So, i need try with IE & Opera? :/

[CloudMax]

All browsers except Firefox works for me. I tried Chrome, Internet Explorer & Opera today to make sure.

I do however keep my browsers up to date at all time, if that makes any difference.

Internet Explorer is by far the slowest browser when it comes to importing textures.

 

Like others have suggested, no changes seems to be applied when using firefox.

That firefox doesn't work for me is actually a good thing. It means that it is a problem that seems to happen to everyone, which makes it easier for me to try and locate the problem. It is very possible that fixing it on firefox will also fix it in chrome for you.

I will look into it later tonight if I have time.

[Jason777]

It may be a problem with particular image formats... What type of images did you edit?

[â–²ChriisTiianâ–²]

It may be a problem with particular image formats... What type of images did you edit?

Fixed! xD

I reinstalled Google Chrome, Firefox, also installed Opera, and got working on all browsers !

BUT!, some images lost his brightness... :/

 

EDIT: Oh also, found bugs:

1) Some images lost his brightness. (ia4 conversion).

2) If you write 0x00 in 0x00000033, the Texture Packer doesn't work.

[Jason777]

 

Fixed! xD

I reinstalled Google Chrome, Firefox, also installed Opera, and got working on all browsers !

BUT!, some images lost his brightness... :/

 

EDIT: Oh also, found bugs:

1) Some images lost his brightness. (ia4 conversion).

2) If you write 0x00 in 0x00000033, the Texture Packer doesn't work.

 

I'm guessing you're trying to modify some of the quest status textures? The game actually forces a particular palette upon them, I think...

 

Take this texture I made for the triforce in the middle of the medallions...

And how it looks in-game...

 

Also, excellent job on this program CloudMax! I'm tempted to take a peek at the source code

[â–²ChriisTiianâ–²]

I'm guessing you're trying to modify some of the quest status textures? The game actually forces a particular palette upon them, I think...

 

Take this texture I made for the triforce in the middle of the medallions...

And how it looks in-game...

 

Also, excellent job on this program CloudMax! I'm tempted to take a peek at the source code

Nope, i'm trying with this: http://www.multiupload.nl/NX6EVFXWN2

No idea why the brightness is reduced.

[CloudMax]

I'm guessing you're trying to modify some of the quest status textures? The game actually forces a particular palette upon them, I think...

 

Take this texture I made for the triforce in the middle of the medallions...

And how it looks in-game...

 

Also, excellent job on this program CloudMax! I'm tempted to take a peek at the source code

Indeed. There are some clear limitations. You can see the result by importing a custom texture, then exporting it again using the texture packer.

Due to these limitations, I made my best to have it set the colors to a *somewhat* good result. I prefer doing it this way over sending error messages saying that incorrect colors are used.

I don't actually remember HOW I do this, but I believe it's some horrible method. Like, if you provide and RGBA image and import it as a greyscale alpha image, it'll just use the red channel for all 3 color channels.

However, this doesn't seem to be what causes â–²ChriisTiianâ–²s problem.

 

And if you do decide to look at the source code, I have to warn you that it isn't pretty. Since it was built on the texture feature from my z64editor, which was built to work with individual OoT Debug ROM files, and has been modified to instead work with entire ROM files, etc. So I made a messy code even messier. Not to mention that I learned lots of things will writing this tool, so it is probably extremely unoptimized.

It is quite a mess, and not really something I'm proud of.

 

Nope, i'm trying with this: http://www.multiupload.nl/NX6EVFXWN2

No idea why the brightness is reduced.

I tried it out, and you're correct. the import of IA4 textures does not appear to be perfectly accurate. My guess is that it doesn't divide by the correct value, resulting in the colors being slightly darker than they should be.

I'll sort it out for the next release. I'll take a look at the other formats as well to make sure that there isn't some issue with the divisions.

 

And I'm glad to hear that the tool actually works after reinstalling the browser. So I guess it does work on up-to-date browsers.

I didn't have time to look into the firefox issue today, but I'll probably do it tomorrow. If I can solve it, this may fix the issue in other browsers, without needing a reinstall, heh.

 

Edit:

Also, about things not working when entering 0x at the beginning of an address. The reason why it doesn't work is simple. It's an incorrect syntax. It doesn't recognize the first parameter of the file name, since it expect it to be 8 symbols long, and not have some kind of prefix.

I COULD make it so that it regonize addresses prefixed with 0x as well, we'll see.

[â–²ChriisTiianâ–²]

More bugs:

Importing a default [P_00013090_message_static] (i4), the textures goes wrong, especially in Sign_Background... :c

[CloudMax]

Sorry for this taking sooo long. I've been caught up in real life, and the little time I've had to spare, I decided to play Lightning Returns which I bought recently.

I'll look into the message textures. Those were last minute additions, I'm not sure if I actually tested re-importing them, which is totally my fault and I should never do so, because it can screw people over.

 

I do however have time now. I'll first look into solving the incorrect textures, then the brightness issue. After that I'll *attempt* to solve the issue with firefox, etc., if I can't find a solution for it quickly, I'll release a quick fix for the first 2 issues.

 

Edit:

I also noticed that the letters in your pack aren't completely white? The do_action texture names are supposed to be white. (As can be seen when you extract the do_action textures with my tool)

I think I might have a different idea as to why it becomes so dark.. though I'm probably wrong.

 

Edit2:

I were not wrong. It seems I were right.

There was nothing wrong with the IA4 conversion. It is simply because your textures aren't entirely white that this happens.

IA4 uses only 3 bits to decide the color. Which means that you're limited to only 8 different shades of grey. (including black & white)

To be more exact, the allowed values are: 0, 36, 73, 109, 146, 182, 219 and 255. (multiply 0 to 7 with 2*(255/0xE) and then round it. Note that the N64 may display *slightly* different results)

The "white (238)" pixels are converted to 0xD. 0xC for the color + 0x1 for the alpha, 0xF would be completely white, and 0xE would be transparent.

The black pixels are converted to to 0x1. 0x0 for the color + 0x1 for the alpha, 0x0 would be transparent.

In other words, the white pixels which had the value 238 now has the greyscale shade of 0xC when converted to IA4. 0xC*(255/0xE) becomes 219 when rounded. This is what causes the texture color to change so much.

So the issue does not lie in the tool. It is simply the game that is limited to 8 shades, which appear to be quite different from what you expected.

Though.. shouldn't 255 be closer to 238 than 219...? the tool does not seem to round to the closest color in this case.

Anyway, the conversion itself is correct, but the part of my code that sets it to the closest available color seems be be slightly off. Could be a result of it rounding at multiple occassions.

 

Edit3:

Located the rounding issue. Basically It would round it to 0xD because that was the closest value. But 0xD is 0xC with alpha, as a result it would become 0xC.

It now round to the closest color instead of the closest color+alpha value. (I simply have to divide it by 2, round, then multiply by 2 again)

So that will be fixed in the next release.

Going to look into the dialog background textures now.

 

Edit4:

The Sign & Ocarina backgrounds were set as i4 textures. They are actually ia4 textures. That's what caused the problem. The default & fading backgrounds were correctly set to i4.

I was just dumb and assumed that they all used the same format.

 

Edit5:

There was an issue with the rgb5a1 import function that I've fixed.

There was leftover code from when I thought the game used rgb5a3 which caused the color calculations to be inaccurate for pixels that were transparent.

However, since it only affected transparent pixels, the problem wasn't anything that could be seen. The only way to see the issue was to look at the generated hex.

 

Guess it's time to attempt fixing the firefox issue.

 

Edit6:

Well, that didn't take long. The very first thing I tried turned out to be the issue.

So, basically this tool is based on my z64editor. And it contains a safety check so that if an image isn't loaded into the browser yet, it simply skip the conversion of that texture and then does the check every cycle until it is loaded, so that it can be converted.

HOWEVER, this code is present in my tool, and is still set up exactly the same way. If the image isn't loaded into the browser, it is skipped. Problem is that my tool doesn't have a cycle or something so that it can just try again.. instead the image is just skipped entirely.

So if the browser doesn't load the image in time, it will be skipped.

I need to set it up so that it waits for each image to be loaded. I have a feeling that I will need to rewrite a big chunk of code.

Unless I just add a new portion to the import that loops through every image of the pack and waits for all of them to be loaded.

 

Edit7:

I was wrong. It was very, VERY easy to solve the issue. I fixed the problem with a simple check. The import functions were already set up to return false if the texture wasn't loaded, so I just had to check if the return value is a boolean. (it returns true if the texture format isn't recognized)

If it is false, the loop will simply check the same texture again until it is loaded by the browser. Seems like firefox simply was slower at loading the images, which is why it was most common on firefox.

https://dl.dropboxusercontent.com/u/6440063/OoT/modding/texture_packer_fixed.png

 

Current 2.3 changelog:

• Solved an issue that caused textures to not get imported if the browser didn't load them fast enough. If changes didn't apply when importing a pack before, it will most likely work now.
• Solved an issue that caused the ia4 importer to round the colors incorrectly in various situations.
• Solved an issue that caused the rgb5a1 importer to set colors incorrectly for transparent pixels.
• Updated two textures in the OoT Debug generator which were incorrectly set to i4 instead of ia4. The textures were sign_background and ocarina_background in the message_static folder.

Going to do some more testing before uploading the new version, but I have been able to properly import my mods texture pack using firefox now, and judging from my console messages, everything works properly.

 

Edit8:

So, I decided to add a bunch of error catches and checks in my code, and add some proper console messages that tells you about them. Trying to prevent any kind of errors and crashes that can appear if you provide incorrectly formated things in a pack. Pointers outside of bounds, addresses outside of bounds, missing folder/file name parameters, etc.

 

New changelog:

• Solved an issue that caused textures to not get imported if the browser didn't load them fast enough. If changes didn't apply when importing a pack before, it will most likely work now.
• Solved an issue that caused the ia4 importer to round the colors incorrectly in various situations.
• Solved an issue that caused the rgb5a1 importer to set colors incorrectly for transparent pixels.
• Updated two textures in the OoT Debug generator which were incorrectly set to i4 instead of ia4. The textures were sign_background and ocarina_background in the message_static folder.
• Incorrectly named folders and images as well as attempting to read/write outside the bounds of the ROM should no longer cause the tool to crash and instead provides an error message in the browser console.

Edit9:

Version 2.3 is out. You can use it online or download it on my website. 2.2 & 2.3 is *not* available on the-gcn. I will uplaod 2.3 when I'm certain that there aren't any serious issues in it.

Edited February 23, 2014 by CloudMax