SoulofDeity

HELL YEAH BITCHES!!! >83 Just finished adding scene / map extraction. It creates the following directory structure: - data | '- scenes | '- scene# (for each scene in scene table) | :- maps | | | '- XXXXXXXX - XXXXXXXX.zmap (for each map in scene) | '- XXXXXXXX - XXXXXXXX.zscene Just need to smack on object table locating and actor table parsing, and this puppy will be ready for distro

so, there's a person I've been helping in another community that's been having trouble ripping models from MM because of the file naming and whatnot. so I'm bringing one of my old programs up to date. Just started it last night, and It's not finished, so far it byteswaps the rom if necessary determines if the rom is OoT or MM based on the internal name locates the file table decompresses files determines file types locates the code file (determined by signature of the last 32-bytes of the file which is the same for both OoT and MM code files) locates the scene table Fyi, like the previous z64dump releases, it follows the rule that nothing is ever hardcoded. It uses smart-searching techniques to find things properly, meaning it'll work on any Zelda rom. Locating the scene table turned out to be a bit of a challenge, but I came up with a pretty good technique: navigate through the file table to find 3 scene files search for the virtual start and end offsets of all 3 scenes in the code file. at least 2 will be found. sort their appearance from least to greatest For OoT: for all the appearances of the offsets that are found, if their difference modulo 0x14 is 0 then the program knows it's inside the scene table. recede backwards from the earliest appearing offset by 0x14 bytes until the 32-bit word at that address is nonzero is not the virtual address of a valid file table entry For MM: for all the appearances of the offsets that are found, if their difference modulo 0x10 is 0 then the program knows it's inside the scene table. recede backwards from the earliest appearing offset by 0x10 bytes until the 32-bit word at that address is nonzero is not the virtual address of a valid file table entry The idea here is that z64dump will use the scene, object, and actor tables to extract and sort files rather than the file table alone. It'll create folders for each scene to match the map files to the scene files, prefix scenes with their scene number, maps with their map number (according to the scene header), and objects with their object number. Actors will be sorted into folders based on their group number, and have their actor/object number as a prefix (ie. aaa:ooo_actorname.zactor). The first 3 entries of the object table will be kept toplevel as they are always the gameplay_keep, gameplay_field_keep, and gameplay_dangeon_keep respectively; and possibily be given 'gk_', 'fk_', and 'dk_' prefixes. for tagging.

could be the output of a program called elftbl in the sdk. not sure. would check but I'd need to hunt down a 32-bit windows image first because all the tools are 16-bit

It could be a problem with the tool you're using. iirc, several of the z64 tools don't actually calculate linesize, width, shift, mask, and dxt of F3 and F5 instructions properly.

The nostalgic look tickles my insides....

just discovered this thread. I think I'm gonna have to create a folder on my desktop for pics and vids of this project labelled "porn".

The answer is: whatever can fit into TMEM. TMEM is 4KB in size, so for i4, ia4 - 8192 pixels (eg. 128x64) i8, ia8 - 4096 pixels (eg. 64x64) ia16, yuv, rgba16 - 2048 pixels (eg. 64x32) rgba32 - 1024 pixels (eg. 32x32) for ci4 and ci8, you also have to take into consideration that TLUT loads the palettes into upper TMEM, so ci4 - 8128 pixels (4096 / 0.5 - 16 * 2) ci8 - 3584 pixels (4096 - 256 * 2) emulator graphics plugins might handle palettes a little differently so you may be able to load ci4 and ci8 textures with the same size limitation as i4/ia4 and i8/ia8, but for hardware compatibility, these are the limits. if you use tile 1 for multitexturing, you'll also need to take it's size into account. EDIT: Sorry, thought I was on the last page, evidently not. Just ignore that (unless you find it useful?)

A new program I just wrote requested by Sanguinetti that lets you generate, fix, and decode 0xFC SETCOMBINE combiner muxes and the clamp/mirror properties of 0xF5 SETTILE. Download SoD's Texture / Combiner Mode Generator I didn't have visual studio installed, so I started writing it in C with the win32 api; but the comboboxes were being douchebags so I just wrote it in Javascript as a .hta hypertext application. If you're a linux user and can't open this, just change the extension to .html and open it in your browser. NOTE: You don't need to have spaces between bytes. The program inserts them for readability

So I realized I never documented this when I was helping someone on skype, so I came back to post it. RECAP ================================================== As said in a couple of my older posts, the 0xFC GBI instruction sets the combiner mode. where the equation is: (a - * c + d;The substituted arguments encoded into 0xFC: a0, b0, c0, d0 = color mode 1Aa0, Ab0, Ac0, Ad0 = alpha mode 1 a1, b1, c1, d1 = color mode 2Aa1, Ab1, Ac1, Ad1 = alpha mode 2color mode 2 should always be set to the same as color mode 1 otherwise 2-cycle rendering happens.the most common blending mode in 3d rendering is 1-srcAlpha; (because the alpha channel actually represents opacity and this converts opacity to alpha; eg. opacity of 0.25, 1.0 - 0.25 = alpha of 0.75). the alpha mode for this would be: (1 - TEXEL0) * 1 + 0which is Aa0 = 6Ab0 = 1Ac0 = 6Ad0 = 7An additional note, K5 should be used in place of 0 when specifying the a0 or b0 fields of the color mode because the fields are 4-bit. THE COOL STUFF ================================================== The F3DZEX microde makes use of 3 tiles: 0, 1, and 7. Tile 0 is the main texture, tile 1 is the subtexture, and tile 7 is used to copy data into TMEM with F0 (for palettes) or F3 (for textures). Knowing this and the information in the recap above, multi-texturing is actually not hard at all. First, load TEXEL0 (tile 0): FD 90 00 00 02 00 22 60 ; set TIMG offset to 0x02002260F5 90 00 00 07 01 44 62 ; assign TIMG to tile 07 and assign it's propertiesE6 00 00 00 00 00 00 00 ; load syncF3 00 00 00 07 3F F1 00 ; copy tile 07 into TMEME7 00 00 00 00 00 00 00 ; pipe syncF5 88 10 00 00 01 44 62 ; assign TIMG to tile 00 and assign it's propertiesF2 00 00 00 00 0F C0 7C ; set tile 00 sizenext load TEXEL1 (tile 1): FD 90 00 00 02 00 22 60 ; set TIMG offset to 0x02002260F5 90 00 00 07 01 40 61 ; assign TIMG to tile 07 and assign it's propertiesE6 00 00 00 00 00 00 00 ; load syncF3 00 00 00 07 3F F1 00 ; copy tile 07 into TMEME7 00 00 00 00 00 00 00 ; pipe syncF5 88 10 00 01 01 40 61 ; assign TIMG to tile 01 and assign it's propertiesF2 00 00 00 01 0F C0 7C ; set tile 01 sizeThen, assign a blending mode. For example, to multiply them together evenly: (TEXEL0 - K5) * TEXEL1 + 0...or to blend additively such as done for the grain of grass in the game: (TEXEL1 - TEXEL0) * 1 + TEXEL0However, if you wanted to use the second texture as an alpha mask, you could do: color mode = (TEXEL0 - K5) * SHADE + PRIMITIVEalpha mode = (1 - TEXEL1) * 1 + 0And don't go apeshit and start hyperventilating if your multi-texture combiner mode can't support shading or primitive colors. That's what the COMBINED argument and color/alpha mode 2 are for. (the COMBINED and COMBINED_ALPHA can only be used color mode 2 and are color and alpha output after mode 1 is processed) To generate combiner instructions, you can use the source to a C program I wrote a while back called fcint. Also, just for the sake of reference, loading a palette... FD 10 00 00 02 00 78 60 ; set TIMG offset to 0x02002260E8 00 00 00 00 00 00 00 ; tile syncF5 00 01 F0 07 00 00 00 ; assign TIMG to tile 07 and assign it's propertiesE6 00 00 00 00 00 00 00 ; load syncF0 00 00 00 07 03 C0 00 ; copy tile 07 into TMEM ((3C0 >> 6) + 1) == 16 colorsE7 00 00 00 00 00 00 00 ; pipe syncEDIT================================================ Just something interesting I found out, 0xDB MOVEWORD can be used to set the physical addresses for segments. DB 06 00 18 80 17 00 00Explanation:[*]DB = MOVEWORD (or rather, write word) to an address specified in a table in dmem [*]06 = index of the segment table offset in the address table [*]0018 = offset to add to address (in this case, 4 * segment number because each address in the segment table is 4 bytes) [*]80170000 = the 32-bit word to write at address[index]+offset A heads up though, the game usually just uses assembly code to set segment offsets. There are only 6 MOVEMEM instructions in the entire game all located within 1 display list in the code file used to set segments 08, 09, 0A, 0B, 0C, and 0D to 0x80127098

I'm not sure, but I think it only affects vertical collision, which is why I drop under stuff and cancel jump up to the other side.

create and import your own maps - easy (SharpOcarina) edit your main character - intermediate (hex editor / f3dzex knowledge or Hylian Toolbox) edit existing characters - intermediate (hex editor / f3dzex knowledge or Hylian Toolbox) create and import your own characters - hard. people have written actors before just not extensive ones. edit/create text - easy (ZTE) edit music - easy (Instred) import your own music - easy (Instred) create and edit cutscenes- intermedate, has to be done with a hex editor with scene format knowledge edit items - swapping models is intermediate; writing assemble code to change how they work is hard. create and import your own items - hard. you'd have to adjust your link script to pin variables to certain addresses as not to break functions for the items you're replacing. create your own/edit existing scripted sequences - intermiate / hard. depends on how much control you need; this ties hand in hand with cutscene editting editing GUI's and title screens - easy,can be done with gs codes and there's a tool written by flotonic (can't remember the name) that can do it

Toying around with the "Press Z to Disable Collision" cheat shown above. Has many wonderful uses... Totally spahming dat shit.

Someone requested a clipping code from me and I didn't have it written down so I had to kinda re-find it. $801DB0B2 // player state%10000000 // lock player state%00001000 // disable jump attack%00000100 // disable player animation / movement updating%00000010 // disable jumping%00000001 // disable map collisionWARNING: You must manually change these back to 0 to undo them, so like if you disable map collision, you cannot touch the ground again until you reset it to 0.Hold Z To Lock Player State-----------------------------------------D01C84B4 0000801DB0B2 0000D01C84B4 0020801DB0B2 0080Hold Z to Lock Player Animation, Speed, and Direction-----------------------------------------D01C84B4 0000801DB0B2 0000D01C84B4 0020801DB0B2 0004Press Z To Disable Collision (walk through walls and floors)-----------------------------------------D01C84B4 0000801DB0B2 0000D01C84B4 0020801DB0B2 0001Disable Jumping-----------------------------------------801DB0B2 0002Disable Jump Attack (Link will still hop and shout)-----------------------------------------801DB0B2 0008

Didn't really plan on making another post since I left the community, but I was helping someone from another website on their project and ended up writing another utility. zobjfix - locates all the displays lists in a file and appends a hierarchy to the end of the file that includes all of them. no usage, just drag-n-drop. this was written because my import script doesn't support importing zobj dlists that aren't pointed to by a hierarchy. search isn't very intelligent. it doesn't follow DE branches or perform recursive memory mapping; it just labells anything that starts with an E7 pipe sync and ends with a DF enddl a display list. io_import_z64_v4 - version 4 of my zobj / zmap import script; animation support added thanks to RodLima from the spriters-resource community. RodLima was new to python when he worked on it, so there's a huge problem with performance caused by lack of file buffering and the segment io system that was already integrated. a single animation could take >= 30 seconds to import. it was fixed later, but I lost the fixed version. when I find it, I'll post that as well. Since the code.google service won't accept new uploads anymore, I moved the svn to sourceforge

I was recently updating one of my svn's and happened across a bit of a dilema. The code.google service is being terminated in 2014. Google has stated they will no longer be accepting uploads and that users should backup their files to another service such as google drive. As some of you know, many modding utilities such as gzrt, uot, zsaten, and ozmav are hosted on code.google. If someone has a lot of free time on their hands, I'd suggest moving them to another service like sourceforge before they're lost.

As some of my closer friends already know, I've lost a lot of enthusiasm for both modding and programming, to the point I have to grit my teeth and bear with it to do either. Over the last couple of months, I've been distancing myself little-by-little from the community, and last week after getting into a petty argument in a group call, I stated that none of them shared my same passions and that maybe I needed to take a break. Then it dawned on me that I've always been a programmer preaching to modders :/ So, I spent the last week isolated in deep thought about this, about what made me aspire to become a programmer, and about what I should do. I became a programmer because I had a dream that one day I'd be able create a gaming company of my own, and that while modding has been a great learning experience, it has never satisfied someone like me who preferably molds things from dust and water with their hands rather than packaged plaster and cast molds. Before I became a part of this community, I had always been socially introvert, and the conclusion that I came to is that my social life and hobbies have stomped on my dream. It's been fun, but I've decided to hang up my coat and move on. Happy Modding, SoulofDeity

The Critic Game Rules Criticize the stated topic to your hearts content (Optional) State a new SINCERE topic (meaning something that is sensible, serious, and reality based) to talk about Example: (start topic = global warming) ------------ person 1: person 2: Topic Start -------------- I think touch screens are useful...ON A PHONE. For gaming, NO. What do you think?

The customer service is great, and it's nice being able to get previous-gen games, but they have no idea how to price their products. I shit you not, one time I went to walmart to check the price on a wii, then went to GameStop directly after and a used wii was more expensive then a new one from walmart.

Hey, I forgot to mention in the first post that anyone can use these ideas if they want, I don't really care. I have several projects going on at once, and this is just something I tinker with when I'm really bored. But anyway, thanks for the feedback also, a couple of more ideas I had [*]let link get hurt while on epona [*]smart bombchus - if you place them with 'A', they'll act like a bomb and you can pick them up or throw them; but if you place it with 'C', it'll run like a normal bombchu. also, change the bomb pickups in the game to bombchu pickups. [*]turn deku stick into poe lantern. instead of swinging it when you press 'C', make link spin it and catch what it hits on fire. (play poe laugh while it swings, lol) [*]if you press the c-button for bombs with the bow out, shoot a bomb arrow

did this for the lulz. couldn't fix the collision, but oh well. was just for fun anyway

The Legend of ZELDA Link's Return Ocarina of Time 1.0 (U) Mod Progress: ~2% Download: N/A Foreword ------------------------- This is just a project I'm tinkering with in my free time for fun. Translation: I'm not looking for a team I'm open to ideas, but I don't care if you're butthurt if I reject them. If I use your ideas or work, I'll give cred. I work on my time, don't bug me about release dates, when I make progress, I'll show it (unless I want it to remain a surprise) Some ideas are outlandish. That's the whole point. They're things I personally think would be pretty damn awesome to see, and wanna have a crack at. I don't even promise all of them will even be possible. The project may never be finished, but regardless, I promise content will be released. I'm making the mod from smaller individual mods, which I'll release the patches to as well for anyone to use in their own projects. Story ------------------------- In the land of Hyrule, there echoes a legend. A legend held dearly by the Royal Family that tells of a boy... A boy who, after battling evil and saving Hyrule, crept away from the land that had made him a legend... Done with the battles he once waged across time,he embarked on a journey. A secret and personal journey... A journey in search of a beloved and invaluable friend... A friend with whom he parted ways when he finally fulfilled his heroic destiny and took his place among legends... Deep in the forest, he was ambushed by a masked imp and robbed of his most precious belonging. He pursued the imp into a strange land, and soon found it was doomed to be crushed under the moon in 3 days. After many hardships, he called upon the ancients to uphold the moon, and cast away the evil from the land. It was at this point the boy realized that he had finally found what he had sought out for, and set out for his homeland with his new friend... Plot ------------------------- Link returns to Hyrule with his new friend Tatl, and sees that much has changed in 2 years. Kakariko is become the village Impa wanted it to be, the Kokiri have new faces and expanded deeper into the forest, and even more importantly, Hyrule itself has united with a northern country. Though not all is well...there is a string of disastrous occurrences happening tied to a strange man. What appears at first to be a simple attempt at breaking apart the 2 countries though turns out to be something much more sinister, and it's up to link to restore the peace by undoing the curses the man placed on all the temples, and then stopping the man himself... Note that I'm purposefully leaving out who it is for the sake of surprise. Gameplay ------------------------- will take place in an extended version of Hyrule; with Hyrule Castle in the exact center of the world map. will play as child link only (Majora's Mask version) seasons and weather will be a key factor in the game and be far more dynamic Gameplay Ideas ------------------------- Hyrule field horse races dynamic seasons and weather. a lot of thought has been put into this involving extending the headers of maps. the full specs are shown below, but keep in mind this is just a concept at the moment, (though I see no reason it shouldn't work) Action Ideas ------------------------- allow link to walk while carrying huge items allow link to put down huge items instead of only throwing them swing hammer horizontally by default make spell animations faster sometime frontflip or somersault when jumping new sword technique - frontflip jumpslash new sword technique - fluent sword combos new sword technique - rolling slash new sword technique - charge sword while running new sword technique - stab while charging sword to do sword beam new sword technique - spin attack while running to do SSB sword spin new sword technique - SSB sword spin in midair to extend jumping distance Weapon Ideas ------------------------ make all items usable as child link replace hammer with iron knuckle axe replace bow with hero bow from MM replace hookshot with MM hookshot double hookshots use farore's wind anywhere fish anywhere Effect Ideas ------------------------ make ganondorf light arrow effect happen to all enemies make magic beans grow in rain What's Already Been Done So Far? ------------------------- I started working on this a few weeks before posting my OoT 1.0 (U) Notes topic, but there was a major change in the gameplay after I wrote the plot, so progress is set back a bit (originally, I was gonna make the game play as adult-link only). But what I am able to keep is the following: front-flip jumpslash front-flip jump new shield design (replaces Hyrule shield) --- btw, lolz, had to write this twice. accidentally refreshed the page XD

some more little stuff... World Map$00852000 216x126 CI8 texture$00858C00 palette Here's a rip as well just in case anyone want it it's paletted, but since it's a png your image editor might not import it as indexed. *shrugs*

Ocarina of Rhyme - Don't Touch Me

I didn't realize it was about gaming only, but my last point still stands.The only argument consoles have really as leverage are that pc games are usually graphically inferior; and that's only because the companies that make the games have very poor 3d artists (*cough*Bethesda*cough*), or because the programmers decide to use low-level graphics extensions that are gpu-specific; so the game looks great for some people but like shit for others.it's really just a tie. both are on equal terms, though the games created specifically for pc are usually inferior.

It matters because if you ignore those things, PC's and consoles are evenly matched. HDMI cable your pc to the big-screen, pick up an x-box 360 controller, and use a program to put your pc into gaming mode first (which btw, can be added to your game's shortcut so you don't have to do it manually every time you play), and the experience is exactly the same.EDIT: And I never said you couldn't do those things on a console, I said that they just weren't anywhere near the same level as pc's feature-wise.