Jason777

Start off with simple things like actor placement and texture edits and gradually move on to more complicated things (what comes after would probably be text edits). Once you get to advanced concepts where no one can really teach you the exact way to go about doing those things (hacking with C and ASM), you should have a decent amount of knowledge of the various file formats of the game. The Z64 wiki is a great place to start looking for information.

Thanks for the positive feedback, Sanguinetti. I realize at the moment that this program won't be of much of use until I can get it supporting SharpOcarina as that is undoubtedly the importer people use now.I made a quick fix with an error that was present when choosing between "far" and "close" display lists in mesh type 0x02. I also fixed a few bugs that could lead to memory leaks. Updated the link.Also, demo video:I've got to get this working for all display lists...

So this is what I've been working on for the past few days (like the whole week): an automatic injector for spinout's animated texture hack written in C++. This program is for intermediate users and I don't expect newbies to understand how to use it. Continue reading for small little notes and some disappointing news. For some reason it doesn't work with maps generated by SharpOcarina (I've only tested v0.6.5) and I've had complete success with Obj2Area (I've only tested v2) I guess due to the way display lists are generated in the programs. The only other bug I can find is that it's tricky figuring out the exact number of display lists in 0x00 mesh types. Besides that little bit of disappointing information, there's no downside to the program besides having a little knowledge on display lists to be able to input correct information. The only thing that the program doesn't do for you is fix the CRC of the ROM. You have to do that yourself if you plan on playing the ROM in PJ64 (nemu ignores CRC miscalculations). Features: [*]Support for all 3 mesh types. [*]Allows you to dig deep into a display list to extract and choose texture commands [*]Includes and uses the scrolling texture hack by default [*]Frees memory in the ROM where the map file used to be. [*]It is completely cross-platform but I have yet to release the source code. I need to clean it up a bit. Things to take note of: [*]This is a Windows executable program. [*]Only usable with custom maps generated by Obj2Area. SharpOcarina is not supported (yet). [*]Due to the way that the original z64-tex-ext hack was coded, you can only have one animation type in a map. The animation can only be paired with a single texture. [*]Besides custom maps, any original map in the game is modifiable with the program (not thoroughly tested, of course). [*]You have to specify your own injection offset for the modified map. [*]JFIF background images cannot be animated. [*]Do not mess with or delete the files "hacks/scroll.bin", "patches/hook.bin", and "patches/run_code.bin"! [*]There is no GUI. Just a command-line program. Planned features (program-wise): [*]Support for SharpOcarina will be implemented as soon as I figure out why it messes up. You won't get a crash, you just have a screwed up texture. [*]Automatic fixing of the ROM's CRC. [*]Automatic injection of map file into first occurence of free space in case you can't decide on an injection offset. [*]More efficiency in using the most minimal amount of space possible. [*]Outputting text files which contain specific information on the map. [*]A menu which allows you to choose between multiple animated texture hacks (in case anybody codes a new one) by reading from a text file which you modify yourself to include new hacks. [*]Texture dumping from the map file so you know which texture command in the display list is for which texture [*]Allow to choose whether you want the program to be verbose with its output or not. [*]All other future changes would be support any future changes in the actual z64-tex-ext hack Planned features (hack-wise): [*]I plan to rewrite a lot of the hack to allow the same animation to be used for multiple textures [*]I also plan to have you be able to insert multiple animation types into the same map file. Download link: http://www.mediafire...grd9qveibdothpo Source (developed with Code::Blocks): http://www.mediafire.com/?e9vc96vyplc0mg5 Credits: [*]spinout for writing the z64-tex-ext hack [*]DeathBasket for giving me some insight on the 0x01 mesh type. [*]Lemmy for writing LemASM which I used to look at the disassembly of hack.bin to find where I could replace the hardcoded texture offsets I had said earlier in this post that the program is cross-platform capable. This means that there is no system-dependent code anywhere within its source. I will release the source code at later time for anybody who is interested in running this program on anything other than Windows. I'll probably make a video of this at a later time. Demo Video:

You're dead on when you say that I've been busy with school. I have Fridays off, though, so I plan on experimenting then. Not to mention the tool I've been writing should be making its first public release on Friday if I continue work on it tomorrow

I'll try replacing a JFIF with an image of different dimensions at a later time to see if there any noticeable changes.

Your assumptions seem to make a lot of sense when applied to the data that is present. Here's the Back Alley's (day) mesh header : 0xB0 : 01 02 00 00 03 00 01 14 03 00 00 00 03 00 00 C0 0xC0 : 00 82 00 00 03 00 01 20 00 00 00 00 00 00 00 00 0xD0 : 01 40 00 F0 00 02 00 00 00 00 00 00 00 82 01 00 0xE0 : 03 02 59 20 00 00 00 00 00 00 00 00 01 40 00 F0 0xF0 : 00 02 00 00 00 00 00 00 00 82 02 00 03 04 B1 20 0x100 : 00 00 00 00 00 00 00 00 01 40 00 F0 00 02 00 00 0x110 : 00 00 00 00 03 07 56 88 00 00 00 00 00 00 00 00 Applying your logic to define the above data... Type : 01 Entries : 0x02 Start of Entries : 0x114 -- Display List 0 Offset : 0x75688 -- Display List 1 (unused) Offset : NULL Number of JFIF Images : 0x03 Start of JFIF 'Settings' Entries : 0xC0 -- JFIF 0 Offset : 0x120 -- JFIF 1 Offset : 0x25920 -- JFIF 2 Offset : 0x4B120 ^^ The offsets line up perfectly with the offsets of the JFIF backgrounds page. It seems you're on to something good, DeathBasket.

I'm starting to think that that doesn't apply to all mesh type 1 entries... take the Temple of Time day scene for example, here's its mesh header along with the data it points to : 0xA0 : 01 02 00 00 03 00 00 E8 02 00 00 00 03 00 00 B0 0xB0 : 00 82 00 00 03 00 7A F0 00 00 00 00 00 00 00 00 0xC0 : 01 40 00 F0 00 02 00 00 00 00 00 00 00 82 01 00 0xD0 : 03 02 D2 F0 00 00 00 00 00 00 00 00 01 40 00 F0 0xE0 : 00 02 00 00 00 00 00 00 03 00 7A E0 00 00 00 00 From what I can see with the information this is provided in the Wiki... Type : 01 Number of Entries : 02 Start of Entries : 0x030000E8 JFIF Image : 0x02000000 Now that obviously isn't right. However, if we look down the data a bit, we find the true offset of the JFIF image : 0x03007AF0 ^ Checked with this page : http://wiki.spinout1...FIF_Backgrounds Start of Temple of Time (day) map in ROM : 0x032DF000 Temple of Time (day) JFIF image in ROM : 0x032E6AF0 0x032E6AF0 - 0x032DF000 ------------ 0x00007AF0

Alright, I have another question! I'm a little confused on how mesh type 1 is structured and I wish to have support for all three mesh types in the program I am writing. Anybody care to explain how it works?

Concerning mesh type 2, I believe a checkbox asking which mesh type the user would like to use would decide the GUI layout for the "Rooms" tab which has two entries for each main OBJ file that is selected. By default, the main OBJ file would be selected as the close display list, and it would be up to the user to choose an OBJ file to be used for the far display list. It would be a pain getting that implemented though. Also, a great option to have is to allow the user to add "buffer space" (empty bytes) onto the end of each map file just incase they need to add something in that SO doesn't support (like z64-tex-ext).

I'm mainly just looking for a way to accurately find free space without worrying about overwriting something. Of course, in unmodified ROMs, there's a load of free space (e.g. 0x35CE040) and most programs happen to utilize that information and insert files at that offset by default without checking if there's some data their already. Basically, I'm writing a program that makes some changes to a map file which increases the size of the map. The change in the file size obviously calls for the file to be moved to free space and have its file pointers fixed. I could just ask the user to input an offset for the map to be inserted at and that would take care of the problem, but for nonexperienced users I would like to create a function which searches for the first occurence of free space to insert the map at.

Everything has its own value representation in text, decimal, hexidecimal, octal, or binary; in just depends on which side of the hex editor you're looking at. Most files within the ROM follow a particular format (scene, map, object, JFIF, cutscene, text strings, etc) and some are just RAW code (actors, functions, routines, etc). To understand what certain bits, bytes, halfwords, words, or doublewords do in a "formatted" file, you could do yourself a great favor and take a look at the Z64 Wiki : http://wiki.spinout1...title=Main_Page

I guess I'll just post here when I have trouble that after researching thoroughly I can't solve on my own (which will be pretty rare). Anyways, the question I pose today that has me kind of puzzled is this... Is there any efficient way of detecting free space in the OoT Debug ROM? I have the idea that doing a thorough search of all the tables within the ROM and recording/comparing offsets would help tremendously but what if someone places custom code at a certain offset? No file table will have a reference to said code's offset. Code snippets are appreciated no matter what language they may be in! EDIT: Well, you actually could find references to the custom code by disassembling certain parts of the ROM and searching for bits of code that made jumps DMARomToRAM or wrote to the special DMA registers. But the again, that's going above and beyond.

Nice map there, DeathBasket; it definitely looks Hyrule Field-y!

Yup, that's the source.

Sorry for my tardiness, I was out with friends and didn't get home till late last night. Besides that, I hadn't yet installed OpenTK. Anwyays... normals are a little better on my map, but it still does it more harm than good. I guess I'll have to do without it. It's a shame, normals really make textures seem so much more lively. Here you go Zeth (I'm pretty sure you know which file to download): http://www.mediafire.com/?ou3ilql0dl3l3 EDIT: I'm actually looking through the source code right now... If I gain a better understanding over OpenTK's library and the flow of SharpOcarina's code (not to mention a basic understanding of C#), I'm pretty sure I can add/something in this program. I already know a lot about C++ and a decent, self-taught understanding of C from looking at a lot of spinout's and Marshall's source code.

Personally, I think the GUI is just fine and the xml based scene settings are clever. The only things which need some fixing up are automatic error checking (such as the injection offset problem I brought up awhile ago) and more customization of polygon types (we're only able to use the definitions available). Another thing that would be nice is implementation of spinout's z64-tex-ext. Of course, I haven't looked at the source code so those are just issues I have noticed at a glance. Zeth, I'll post the compiled fix later when I get back on the computer.

I was using the latest release (v0.6). I'm thinking about going and compiling the source, though, as that seems a bit more updated. So changing this: if (IsOutdoors == true) { VertData.Add((byte)System.Convert.ToByte(((int)(VertList[j].Normals.X * 255.0f)) & 0xFF)); VertData.Add((byte)System.Convert.ToByte(((int)(VertList[j].Normals.Y * 255.0f)) & 0xFF)); VertData.Add((byte)System.Convert.ToByte(((int)(VertList[j].Normals.Z * 255.0f)) & 0xFF)); ... To this: if (IsOutdoors == true) { VertData.Add((byte)System.Convert.ToByte(((int)(VertList[j].Normals.X * 127.0f)) & 0xFF)); VertData.Add((byte)System.Convert.ToByte(((int)(VertList[j].Normals.Y * 127.0f)) & 0xFF)); VertData.Add((byte)System.Convert.ToByte(((int)(VertList[j].Normals.Z * 127.0f)) & 0xFF)); ... Should result in better normal calculation? I don't really know much of normals other than how they change the lighting of a texture.

Ah, my map is has a lot of weird "broken" polygons in it anyways, so I doubt your normals calculation is entirely to blame. Thanks for the info, xdaniel, it works perfectly.

Imagine base jumping off of that...

Welcome to the forums! So I assume you (used to) mod SM64? I have quite an interest in that game since alot more of it has been documented than OoT/MM but I'm a little too attached to move on...

So I tried importing a map with SharpOcarina today and found a few errors with the vertex color (normal?) calculation. Thank god I'm not getting UV out of range errors, but those vertex normals are quite noticeable... Especially when the sun rises, sets, or it is nighttime. It may just be that I've triangulated the hell out of that map, but I figured I should give you a look, xdaniel: (There are a lot of images, so I put it in a spoiler tag...) Is there an option to disable normals? I know that Obj2Area had the option and that would probably be of the most help to me.

These are the type of mini-mods that I enjoy.

The thing with the item amounts is that it tries to decrease the deku seed amounts and not the arrow amounts even if an arrow is spawned (I assume it's because of the routine that sets up the deku seed spawning for child link in the ovl_player_actor). To combat this, I add 1 to deku seed amount (if the arrow actor that was spawned has a variable of 0x0002, 0x0003, 0x0004, 0x0005) while subtracting 1 from the arrow amount. The result is that the deku seed amount remains fixed. Example: If you use an arrow... Deku seed amount = 19; 19 + 1 = 20; ... then it tries to decrease the deku seeds as usual. 20 - 1 = 19; ... this maintains a fixed amount for the deku seeds. ... while decreasing the arrow amount. Arrow amount = 19; 19 - 1 = 18; ^ A hackish fix but it works. One other thing that you may have not noticed is that when decreasing magic, the yellow part of the magic bar that shows how much magic was lost does not appear. Yup. That pisses me off, too. It won't allow me to watch the video on any mobile device except through a special hole in the security (it's only available only to the uploader as far as I can tell). I'm thinking of reuploading the video with different music to see if it fixes anything.

This is for a seperate project that I am working on and normally I wouldn't release content like this, but... so far, I haven't seen a fix for the bow and some people might need this for there own projects (besides, this isn't completely custom). Took me long enough, eh? I'll release the source along with the patch at a later time: http-~~-//www.youtube.com/watch?v=7-M73wYsqFE&feature=plcp That was the result of... Display list porting Two ASM hacks Fixing display list pointers in code.zdata Fixing item enabling in ovl_kaleido_scope.zdata For those of you, who had seen the original source code on here (didn't work properly)...: Original Source^ It should be noted that the lines of code was reduced quite significantly (and it actually works). I may fix the positioning of the arrow spawn and the bow string. Anyways, there's only two bugs with it that I can see so far. Also, I suck at making cool videos.

That's awesome stuff, xdaniel. I wish I knew how to do these things