[Lightpost]

Update:


Noob here working on my very first N64 Retexture Project. I need a little help with a few things regarding Hex Editing but I'll discuss it at the end of this post.
I'm using Phantom7's Hi-Res Texture Pack as a basis and replaced a few of the textures with the ones Disbala used for his Twilight Princess - Skyward Sword Texture Pack. I haven't played Skyward Sword nor Twilight Princess yet (I'm such a loser).

I've only retextured most of Kokiri Forest, a little in Lost Woods, Link's clothing and equipment, some parts of the HUD which I'd say is about 90% complete after two weeks of working on it. Screenies below.

WARNING!

Bright textures used. Take time to stare at each of the A Link to the Past, Minish Cap and Wind Waker screenshots below. This will help you adjust to what you're about to see. This way, you won't damage your eyes. 







.


.


.

Okay, sorry about that. Here they are.

[You can click each image to increase its size a bit]


^ I like how the paint blotches become more obvious whenever you get too close to a texture, especially the tree bark here.





I know Kokiri Forest is supposed to look dreary. If ever I get my hands on all the textures found in Skyward Sword, I'll use the closest images to replicate the atmosphere of each area. With Disbala's texture rips, I won't get as far as Death Mountain . With the bright textures I'm currently using, Kokiri Forest's background music fit very well.

If you look at the Great Deku Tree's leaves, you'll see those black silhouettes. I've yet to find that image in the dumped ones to edit it.









I made the texture for the Gossip Stone myself as there were no textures for it in Disbala's pack. I tried to imitate Skyward Sword's version as close as possible but this is the best I can come up with. I'm only using Paint.NET by the way.



^ I went as far as to bother retexturing the log tunnel interiors.





^ I managed to create a tunnel exit illusion with this one .
I even bothered editing the house entrances (below).





You can see it's actually link's bed.




Disbala's Texture Pack didn't have any sign board textures so I just added an Oil Painting Effect on Phantom7's version.




^ My version of the background trees. A collage of the Skyward Sword trees and plants.




^ The textures I used for the walls in the Lost Woods looked like the ones I should use for Kokiri Forest instead of the bright Faron Woods version.








^ I only like how his Skyward Sword boots version look like on him.

Okay, now here's what I need help with:

-Has anyone finally succeeded retexturing Link's stubborn bracer/gaunlet forearms, belt and his adult version's hair in the back? And also the NPC house interiors in Kokiri Forest?

-I know that his clothing textures are some sort of masks so using the actual Skyward Sword textures won't work as it will only darken his tunic. I've Googled about Hex Editing it and managed to make it work on the Debug version of OoT (ZELOOTMA). However, the offsets are different on the regular OoT ROM. I'd really appreciate it if someone can provide me the values I need to Hex Edit so I can change it to white.

It also appears that the HUD elements work the same way as Link's tunic - a somewhat pre-colored surface which can also be edited. I also need help locating those values in the ROM so I can use the Skyward Sword sprites I obtained and make its colors appear accurately in the game. The same thing goes for the Text/Dialogue Boxes.

-I also noticed how the textures on his large sword scabard gets inverted whenever Link's far from the camera - I can put up with that. What I don't get is the scabard tip. I found the two dumped textures for it but whenever I edit one, it looks messed up (grainy pixels) instead of the game just using the default textures. What's up with that?

So far that's all I need assistance with.

Please, please, please help me with this one. Google's hiding things from me/I don't know where to look at.

 














     

[Rhys]

I'm pretty sure each texture is CRCed in RAM and that CRC is used for the filename. If certain textures aren't showing up, then the CRC is different for those textures in your copy of the game.

You could try re-dumping them, that way you'd have the right files.

[Lightpost]

I'm pretty sure each texture is CRCed in RAM and that CRC is used for the filename. If certain textures aren't showing up, then the CRC is different for those textures in your copy of the game.

You could try re-dumping them, that way you'd have the right files.

Thanks for the input. Sorry though I forgot to say I'm a noob and this is my very first attempt at N64 retexturing.

It is weird though. When I pasted the original/unedited _ciByRGBA image (which I guess is what you mean by re-dumping), the game loads it properly. I didn't touch the file name after editing that particular image. I don't understand why it won't load. 

I'll do a bit of Googling and hopefully I'll find some answers. 


Update:

I found out what I did wrong and finally got it to work!!! 

I tried comparing those testy PNGs to those "rgb" and "all" by checking its Properties (right-click) and then comparing infos found the Summary Tab. It turns out that those PNGs were somehow just 24 bit files.

Whenever I saved those edited _ciByRGBA images, Paint. NET opens the "Save Configurations" window, I just clicked OK, leaving the the "Bit Depth" option on "Auto-dectect." I didn't bother selecting "32-bit," that's why it got saved as a 12-bit image. 



I'm trying to make a Skyward Sword Texture Pack 

[Dashman]

That looks quite nice.

Now, I know this is gonna be a bit impolite, but you're the first person I've seen around working on an N64 game's retexture and I'd like to ask you a couple of things about the process.

Turns out I'm working with a group of guys translating a Gamecube game by retexturing its dialogues and at some point we thought the same method could be applied to N64 games, specifically Super Robot Taisen 64. We gave a try at dumping the dialogue textures using Project64 (not sure if 2.0 or a K7E build) with some plugin (most likely Glide64), which resulted in a LOT of small textures for every single dialogue box.

I'm assuming you're working with a collection of already dumped textures, so you probably don't know much about dumping, but if you do, did we do something wrong or that's just how the textures are and there's no changing them? Also, what's the recommended settings for dumping textures?

And in case you don't know anything about dumping, how big are the textures you're using? I mean, how many textures are used for the sword icon on top of the screen, for example? Just one or is it divided in several textures?

Thanks and good luck with your project! And sorry for the little derailment!

[Lightpost]

That's okay.

But I'm sorry though, I really haven't gotten that much into retexturing yet and Google only lead me as far as http://www.emutalk.net/ for help. You should check out that site.

So far, I really don't know why you get duplicates of each textures.
Yes, your assumption is right. The existing texture pack (Phantom7's) I'm using mostly has sorted out the ones that Project64 uses but I still found a few duplicate images he edited. And no, I just started learning about retexturing two weeks ago so I still haven't grasped the idea of dumping. 

 I guess you should just try editing each one and see what image with a certain file extension (the part before the .PNGs) would show up in the game. Once you find out which file works, you should then just use the same for each texture. Note though that in the game I'm editing, it seems that some textures have duplicates for a reason. Whenever Link is far from the camera, his boots and sword scabard uses an alternate probably lower resolution of the same texture. I'm not sure though if that's the case with the game your editing.


Goodluck! 

[Zoinkity]

...managed to make it work on the Debug version of OoT (ZELOOTMA)...I'd really appreciate it if someone can provide me the values I need to Hex Edit so I can change it to white.

All files in the debug versions are uncompressed.  It's actually an offset within a compressed file, which is why you don't see it.
I'd need to know exactly what version you need the fix for.  It would be different in different revisions. 

What's actually happening with these though is that the textures themselves are white.  On a lower level, the display lists are treating these images not so much as black & white but as foreground & background--similiar to how gradient tools work.  As a result, they can set B&W to two different colors, or even transparency assuming the combiner permits it.

Exploiting this, Link only has one tunic.  They use a table of ~3 values for the different tunic base color, replacing white with the color.  A little pointer redirection is all you need to turn that into many other custom colors though.

We gave a try at dumping the dialogue textures ... which resulted in a LOT of small textures for every single dialogue box.

This is correct.  Non-Nintendo hi-res texture replacement is based off the textures as they hit the plugin.  At a low level, the RSP microcode is slicing up textures into sizes that fit the texture buffer and rendering triangles.  Since a, say, 180x64 text box will never fit into tmem on its own, they slice this up into textures that fit and render each slice as two triangles.

BigN's own texture replacement scheme uses a different set of checksums and addressing, physically replacing the original image with another in-code.  This has some limitations, as they can't go beyond certain resolutions in most cases, but overall works well.  I believe they're in 8xX interlaced segments or something like that. 

Why not just do an actual romhack for the text boxes?  If it's a matter of compression or insertion or something I can always assist.

Oh, as for textures changing at a distance, there are two potential causes.  Mipmapping is one, and the other is due to different application of the same texture in low-resolution distance models.  Level of detail effects can also be a problem, but its not common enough of a case to mention in detail.

[Dashman]

Why not just do an actual romhack for the text boxes?  If it's a matter of compression or insertion or something I can always assist.

That would be ideal, not only for the text boxes but for the menus as well. The thing is, none of us know a thing about romhacking outside general terms, and only got into translating the other game (Super Robot Wars GC) because retexturing made it relatively easy. I wouldn't know where to start with an N64 game romhack, to be honest, but if you can give me some pointers I'll eventually look into it.

Also, this is looking gorgeous, Lightpost, keep it up!

[Lightpost]

All files in the debug versions are uncompressed.  It's actually an offset within a compressed file, which is why you don't see it.
I'd need to know exactly what version you need the fix for.  It would be different in different revisions. 

Thanks Zoinkity. I actually tried comparing the debugged version with the US ROM I have. I finally got it to work. I just got confused with the offset values and forgot that the Hex Values it point to are two different things. What I did was to use the offsets I Googled for the debug version and find the Hex Values in the ROM I have, which I decompressed with ZDec. The Skyward Sword texture for his tunic now looks as it should after I made his tunic white.

I'm now working on the Hearts, trying to make the pale sprites for the Skyward Sword version appear as is in the game. It was a bit confusing because each R G B values were somewhat scattered but I managed to change it to white. But just like what you said how the textures applied to it act as some sort of a gradient, the pink Skyward Sword heart sprites became a vivid red. I'm thinking if it's possible to make it transparent?

Also, do you have any tips or sites you can point me to with tuts on how I can find certain objects in the game? After I manage to make the HUD appear how I want it to, the last thing I'd like to work on are the text/dialogue boxes and if possible, changing the font style. I just don't know how to find it in the ROM for editing.

Thanks a lot for clearing things up for us!

[Zoinkity]

Aegh, this is what I get for not hopping on the Zelda bandwagon ;*)

I'm thinking if it's possible to make it transparent?

Matters what the combiner settings are.  Actually, if you throw a read breakpoint on those RGB values chances are good that there's a bit of code assembling them into an output DL.  Even when channels are ignored the N64 always expects RGBA values.  My money is on them hardcoding the alpha to 0xFF before storing the command, so a little ASM hack there would fix it--if alpha converge (or whatever mode it was) is permitted. 

That's guesswork though.  I'd have to trace it to know what's going on and that would take minutes of work ;*) 

Also, do you have any tips or sites you can point me to with tuts on how I can find certain objects in the game?

Wish I was more familiar with the title now.  The filelists used in the Utility of Time use filenames that indicate what each file is, and those were created by the hacking community so they should be somewhat useful.  Doesn't help for finding data inside it, but where you go.
The in-game debugger can be used to load certain objects if memory serves.  It's in all versions of the game to some degree and codes to activate it are .

As far as where their community currently is, a good bet is to try http://z64.spinout182.com/index.php
In the past there was a lot of drama between different branches and splinters of Zelda64 communities, and the end result was driving interested people away and tying up info in particular cliques.  It looks like all of that's blown over, but to be honest it isn't clear where the community is at any longer.

[Marcelo_20XX]

You can change the font style if you retexture the letters, every letter is stored as a unique texture. Also don't use Glide64 "Final" for dumping textures use instead Rice's video as that plugin can dump all the textures loaded into RAM and not only a few like Glide64 does

[Zoinkity]

Those two use different naming conventions though, and its a little sketchy how interchangable they really are.  Starting over from scratch probably isn't a good idea at this point, though porting it to the other format as well is a very good idea.

You're lucky Zelda's in a position where plugin support is relatively good.  Rice's consistant lack of support for low-level triangle commands and certain combiner modes makes it unsuitable for other games. 

[Marcelo_20XX]

For dumping purposes, Rice is the superior option (Mudlord's build), for general gameplay ofc it is Glide64. While I was retexturing OoT I came across a problem with Glide64 not dumping a lot of textures and making my job harder than it should be. And about the name convention, there is only one format currently supported and that is Rice's (the other is Jabo's format but no pack uses it) and they are totally interchangeably, just make sure to use "Full TMEM Emulation" under Texture Enhancement options before dumping the textures...

@Dashman
Most N64 games stores its fonts as separate textures for each letter, number and symbol. So the only thing you can do its to romhack the game...

[Zoinkity]

Come to think of it I don't think Glide dumps ia4 images.

Under normal circumstances you can restyle a font; you just can't add chars, manipulate strings, etc.
Pretty sure Zelda copies each char from ROM on-demand; that means you can wind up with dozens of possible locations for the same char in the same context due to dynamic allocation.  If it kept its samples in rdram that wouldn't be an issue and you'd be looking at restyling only a handful of the same samples (thanks to different mipmaps of the same image).  You'll probably be in a position where it's generating way too many possibilities, so a hardcoded hack is the only viable option despite the limitations. 

Funny enough, the font tables themselves are rarely set up on an individual char basis unless they're variable width and height.  The vast majority are either in-line or in block format (almost always 16 per row).  It looks like they're individual though, since blocks are copied out of the table itself when loading the image in tmem.

(offtopic)
Interestingly though, depending on how the game generates strings there are cases where you can alter strings that are printed.  A few, Virtual Pro Wrestling among them, will generate a temporary texture from a string.  This reduces overhead since you only have to assemble it once, and non-BigN texture replacement only sees the generated texture and not the individual chars that generated it.
That's something of a special case though.  It's only really pertinent for games that 1) doesn't have their font tables uncompressed or always loaded and 2) are using a non-standard format (as in directly interprettable by the RSP).  VPW uses a 1bit font kept within a compressed file, so 1-time string generation cuts out a lot of processing.

Then you get into all the Japanese-exclusive titles that don't even bother with fonts.  They're all text block images.

[Dashman]

@Dashman
Most N64 games stores its fonts as separate textures for each letter, number and symbol. So the only thing you can do its to romhack the game...

Yeah, I ran some tests again with Rice and noticed that the text in text boxes is dumped as single characters. The text in the introduction is stored as a single image, so it got dumped as pieces and misleaded me into thinking a translation was possible through retexturing. At least, character portraits and the mechas themselves can be retextured just fine, and some of them can really use a facelift in this game!

[xdaniel]

As far as where their community currently is, a good bet is to try http://z64.spinout182.com/index.php
In the past there was a lot of drama between different branches and splinters of Zelda64 communities, and the end result was driving interested people away and tying up info in particular cliques.  It looks like all of that's blown over, but to be honest it isn't clear where the community is at any longer.

To add to the community question, the most active Zelda 64 community probably is part of The GCN at https://www.the-gcn.com/index - It's not strictly a Zelda community, more like general gaming and such, but most of the still active OoT/MM hackers are on there and projects, research, etc. related to the games make up a big part of the forums. That said, spinout's wiki at http://wiki.spinout182.com/w/Main_Page is still one of the most important resources regarding documentation, even if the forums are kinda dead.

(Also, I'm really quite glad that it's finally spreading that the worst in terms of drama is behind us. Finally shedding that horrible reputation we've had since ZSO.)