Twili

Extremely old news. These are from Zeth's Photobucket, and he posted them on the Project64 forums in 2009 here.

I expected it to break the others...but now we know where bones get assigned, just not how to handle multiple options for them in the same prms chunk... It can only improve over time, right? I'll keep looking into it.

I have a small piece of information that brings us a step closer to animation support! In the debug log for link.cmb (zelda_link_boy_ultra.zar): -- PrmsChunk -- Unknown (1): 0x1, Unknown (2): 0x0 Index count: 0x1, Index offset: 0x18 Prm chunk offset: 0x1C Index #0: 0x5 And babydodongo.cmb (zelda_dodojr.zar): -- PrmsChunk -- Unknown (1): 0x1, Unknown (2): 0x2 Index count: 0x4, Index offset: 0x18 Prm chunk offset: 0x20 Index #0: 0x3 Index #1: 0x2 Index #2: 0x1 Index #3: 0x4 [insert another example here.] These "Index" values are actually bone ID's! I don't know how to determine how the bones are assigned when the "Index count" is greater than 1, but when it's equal to 1, you can apply the designated bone's transformations to the primitives drawn. This should make the "ultra" models and the models in zelda_spo04_objects.zar recognizable instead of bunched together. I'd like a screenshot of that if it works.

I think the topic title is a bit misleading. People that don't bother looking at the other pages may assume, particularly due to the Utility of Time talk, that this topic is just the nth topic pertaining to custom models for the N64 version of OoT. I'm here to make clear to anybody using the getnewpost function that this is in fact about the 3DS version of OoT, and since the viewer has been released now and a cryptic #zelda IRC channel mention is being thrown around, the server is irc.badnik.net for those wanting to chat with us.

And I finished up my import, but it still only works in Nemu64, but it also uses Hyrule Field's instrument map now.

I use MidiEditor. Sample image taken from the link. If it's your first time running this after installing it, you may need to go to Midi > Midi Settings and check whatever is in the "Send Output to:" box, then click Ok. Then open a MIDI that has multiple notes playing at once. The tracks are color-coded. Click on the Tracks tab seen below, and you can hide and mute the tracks that you aren't editing. It won't affect the MIDI at all. You do this by clicking the eye icon and volume icon (third and fourth from the left) in the track entry. For each set of overlapping notes in a track, click the "Add Track" button and it will ask you to name the track. After you have created a new track, highlight one set of notes in a previously-existing track that overlap other notes by holding down Shift and clicking and dragging. You may have to do that in small amounts, because it can be finicky and deselect all of the notes, and you might also click and drag notes out of position by mistake. If that happens, just do Ctrl + Z. Each time you have highlighted some notes that you want moved to another track, do Edit > Move selected Events to Track... and the ones at the bottom should be the new tracks that you created, so keep track of them. Again, this is the sample image taken from the SourceForge link so you can see what the interface is like. I didn't take that screenshot and my name isn't Markus. Using this method, you can achieve amazing results like this: I still cut out some of the notes, though, because I don't know if there's a limit to the number of tracks a sequence can have, and I was playing it safe. DeathBasket also said that you shouldn't have more than four simultaneous notes playing at once by the same instrument. The most I have is three. And that's a WIP, by the way, which only works in Nemu64, for some reason...

I'd just like to thank you for this tool, because I think it will come in handy for a mod I may start up, but I dunno yet. And by the way, please check your PMs. I'm sorry if it's overkill asking you here.

Change (almost) all GameCube colors back to N64 colors: 0x00B7DBBB: 0xFF -> 0x96 0x00B7DBEF: 0x96 -> 0xFF 0x00B7DC15: 0x26 -> 0x38 0x00B7DC1D: 0x26 -> 0x38 ^ A Button icon on musical staff. 0x00B8808B: 0xFF -> 0x96 0x00B8809D: 0xEE -> 0xE0 0x00B880AB: 0xC8 -> 0x5A 0x00B880AD: 0x03 -> 0x0E 0x00B880B5: 0x23 -> 0x20 0x00B880BF: 0x32 -> 0xFF 0x00B880E1: 0xC0 -> 0xCF ^ A & B Button in HUD. 0x00BCAB6B: 0xC8 -> 0x50 0x00BCAB6D: 0x50 -> 0xC8 0x00BCAB71: 0xFF -> 0x82 0x00BCAB73: 0x82 -> 0xFF 0x00BCAB7D: 0xFF -> 0x82 0x00BCAB7F: 0x82 -> 0xFF ^ Text box cursor. What's missing: A Button highlight after successfully playing a song at a musical prompt, Start Button when paused, aura around Game Over/Save options. Anyone want to tackle those?

I attempted to load object_oB1 (alpha version of the bazaar/shooting gallery guy) over object_ossan, and the game crashed...but it was a less severe crash than previous attempts; the header for object_oB1's hierarchy lacked a display list count, and adding that allowed me a glimpse of the model as the shooting gallery was fading in, with the framerate remaining constant instead of dropping below zero with a completely black screen. What I did was overwrite the first 0x66B0 bytes of object_ossan with all of object_oB1's file, and then chose an animation from object_o_anime to add to my modified object_ossan. I used UoT SVN R10 to view the animations in object_o_anime and decided to use the one at 0x1300 (erroneously marked 0x1304 in UoT). So I copied the 0x480 bytes of data for the animation (beginning with the rotation values at 0xE90, ending with the header) and pasted them at 0x66B0 in the modified object_ossan. I recalculated the two pointers in the animation header so they read 060066B0 06006A34 instead of their original 06000E90 06001214. The header for the animation was now at 0x6B20. To add the display list count to the hierarchy header, I copied the hierarchy (first 0x268 bytes of object_oB1/my modified object_ossan) and pasted it at 0x98D8. This way, I wouldn't have to recalculate all of oB1's data pointers just because I added four bytes to the hierarchy header. AND, this way the header would end up in the exact same spot object_ossan's old one was (0x9B38). So, I didn't actually insert any bytes because I could just change 08 00 00 00 (untouched from object_ossan's header which has a display count) to 0F 00 00 00. Then the pointers to the limbs had to be recalculated. For convenience if you want to help solve the persistent crash issue (and I want you to help!), these are the new pointers: 060098D8 060098E4 060098F0 060098FC 06009908 06009914 06009920 0600992C 06009938 06009944 06009950 0600995C 06009968 06009974 06009980 0600998C 06009998 060099A4 060099B0 060099BC 060099C8 060099D4 060099E0 060099EC 060099F8 06009A04 06009A10 06009A1C 06009A28 06009A34 06009A40 06009A4C 06009A58 06009A64 06009A70 06009A7C 06009A88 06009A94 And the header just past the limb pointers should look like: 06009AA0 26000000 0F000000 Now, the things that I changed in ovl_En_Syateki_Man: ADDIU instruction at 0x64 from 24E70338 to 24E76B20. ADDIU instruction at 0xF0 from 24840338 to 24846B20. ADDIU instruction at 0x10C from 24A50338 to 24A56B20. (Animation pointers.) Also these: ADDIU instruction at 0xC44 from 24010008 to 24010017. This previously selected the 8th limb (index value 7+1) of object_ossan's hierarchy (the head) to load the shooting gallery variant of his head. Limb 0x17 (index value 0x16+1) of object_oB1's hierarchy is his head. ... ADDIU instruction at 0xC58 from 27397E28 to 273932F8. (0x7E28 was the shooting gallery version of object_ossan's head display list and 0x32F8 is object_oB1's head display list.) Once you paste the modified actor and object files at their rom offsets and test in Nemu64, you should be greeted by the following images: Child Shooting Gallery: Adult Shooting Gallery: NOTE: I adjusted the brightness and contrast, because like I said at the beginning of the post, these were taken when the area was fading in. So yeah, help on the freezing appreciated. I think it's more stuff that has to be done to the actor. Because everything is pointed to as it should be in the object, and I changed the animation pointers in the actor. The fact that oB1's left arm is extended in an animation-defying way might be significant.

I'm EXTREMELY curious how you managed to load her with Saria's final actor, what with the difference in limb counts, because I've attempted such a thing in the past and it always froze for me if the limb count was different than the amount the actor expected. Possible tutorial in the future?

I figured that I should post any interesting OoT 1.0 information that hasn't been widely documented, or at all, for that matter, in here. These are the ram offsets of 64DD-related functions/data tables: (AND YES, ANY FUNCTION NAMES THAT LOOK IDENTICAL, BUT ARE PRINTED IN A DIFFERENT CASE, ARE DIFFERENT FUNCTIONS! IT'S HOW LIBLEO LABELS THEM!) 0x801ca740,LeoReadWrite 0x801ca7d0,leoInitialize 0x801ca9a4,leoCommand 0x801cab04,LeoReset 0x801cab94,__leoSetReset 0x801cabb8,LeoResetClear 0x801cac40,leointerrupt 0x801cb640,leomain 0x801cbabc,leoRead_system_area 0x801cbcd0,LeoGetAAdr2 0x801cbd30,leoRead 0x801cbd5c,leoRead_common 0x801cbef0,LeoLBAToByte 0x801cc040,leoInquiry 0x801cc0f0,osLeoDiskInit 0x801cc190,LeoReadDiskID 0x801cc1f0,leoReadDiskId 0x801cc380,leoAnalize_asic_status 0x801cc48c,leoChk_asic_ready 0x801cc574,leoChk_done_status 0x801cc728,leoSend_asic_cmd_i 0x801cc7d0,leoWait_mecha_cmd_done 0x801cc820,leoSend_asic_cmd_w 0x801cc858,leoSend_asic_cmd_w_nochkDiskChange 0x801cc944,leoDetect_index_w 0x801cc96c,leoRecal_i 0x801cc994,leoRecal_w 0x801cc9bc,leoSeek_i 0x801cca20,leoSeek_w 0x801cca5c,leoRecv_event_mesg 0x801ccab0,leoChk_err_retry 0x801ccbc0,leoChk_cur_drvmode 0x801ccc00,leoDrive_reset 0x801ccc30,leoChkUnit_atten 0x801ccc3c,leoRetUnit_atten 0x801ccc70,leoClrUA_RESET 0x801ccc8c,leoClrUA_MEDIUM_CHANGED 0x801ccca8,leoSetUA_MEDIUM_CHANGED 0x801cccc0,leoInitUnit_atten 0x801cccd0,LeoSpdlMotor 0x801ccd90,leoC2_Correction 0x801cde80,leoSet_mseq 0x801ce030,leoStart_stop 0x801ce120,LeoDriveExist 0x801ce1f0,leoMode_sel 0x801ce2a0,leoRd_capacity 0x801d94f0,LEOfirmware_rev 0x801d94f8,LEOBYTE_TBL1 0x801d9504,LEOBYTE_TBL2 0x801d9518,LEOVZONE_TBL 0x801d95f8,LEOZONE_SCYL_TBL 0x801d9618,LEOVZONE_PZONEHD_TBL 0x801d9688,LEOZONE_OUTERCYL_TBL 0x801d9698,LEORAM_START_LBA 0x801d96a8,LEORAM_BYTE

The compression scheme in Mario Party is amazingly simple, like a bastardized version of the three big N64 ones, but I can't seem to figure out how the final piece of this puzzle works. My examples will be from the Japanese ROM. This file at 0x31BDCC, and all of the others pointed to from various tables, has a header consisting of two words: 00000558 00000001 The first word is the decompressed size of the file. The second word is a flag that is either set to zero or one. 00000001 means that the file is compressed. Since this file is compressed, it's laid out the following way: Everything immediately past the 8-byte header will first be a "control byte." If it's set to 0xFF, it means that there will be 8 bytes of raw data immediately after that can be copied to the output file. This happens twice in a row right after the header in the example file: [FF] 46 4F 52 4D 00 00 05 50 [FF] 48 42 49 4E 4D 4F 44 45 But if it's anything less than 0xFF, you have to look at the binary representation of it, which is the case for the next "control byte" in this file: [AE] (10101110) The bits are read from right-to-left and dictate the format of the data immediately after the control byte. If a bit is set to 0, there will be a pair of bytes that tell how to manipulate the output file for repeating values. If a bit is set to 1, it represents a single byte of raw data for the output file. So, 10101110 is read right-to-left. It means that the data after the control byte should be grouped like so: [bB C0] 20 00 02 [b9 C2] 01 [b6 C5] 16 0 1 1 1 0 1 0 1 (Immediately after this data will be another control byte, and this cycle repeats until the end of the file.) Enclosed in brackets are the byte pairs for manipulating the output file. Outside of brackets are the bytes of raw data. So, obviously the bytes of raw data get copied in order as they appear, but I'm stumped on exactly how the byte pairs in brackets should be interpreted. That's what I need help with. Anybody have an idea? Something to keep in mind: I've seen another file that's already decompressed in the ROM that contains data that can be seen in this compressed file, so I have reason to believe that the next 4 bytes in the output file should be 00 00 00 20. (20 from the raw data bytes above.) So the byte pair BB C0 should produce three 00 bytes before the 20 byte in the output file. Also, I think that the file header should be copied over to the output file.

Dropping this here.

Updated with another program. The object extractor is next to come.

This: else if(a<57){fseek(rom,1,SEEK_CUR);} should be changed to else if(a<58){fseek(rom,1,SEEK_CUR);if(a==56){fseek(rom,-1,SEEK_CUR);}} This is a hack to fix the issue of "Z2_8ITEMSHOP" being gotten as "temshop" instead of "itemshop" due to this scene name being an exception to the number rule, having only one digit. And does anyone want two more extractors to get the overlays and objects with names? They'll come with external files, one with the overlay names taken from the MM debug rom and the other with names I think the objects would have since the debug rom lacks names for them.

UPDATED THE LINKS TO FIX A MINOR ISSUE. What makes this one perfect is that the previous one, while getting the correct scene names, didn't eliminate unnecessary parts. For example, the old one would have extracted "Z2_22DEKUCITY_scene.zscene" while this new one extracts it as "dekucity_scene.zscene." It eliminates the Z2_ prefix and any numbers that are before the actual descriptor and makes it lowercase. The text document this generates now lists the offsets of all of the scenes and maps labeled like the extracted files, minus the .zscene/.zmap part. Scene/map extractor source (platform-independent): http://pastebin.com/HKYY1dKM Scene/map extractor Windows EXEcutable: http://www.mediafire.com/download/i9vgc19c70u0v1w/names.exe NEW! Overlay extractor: http://www.mediafire.com/download/qkvp28shbdj1ah9/ovlnames.zip Contains ovlnames.c (the source), ovlnames.exe (Windows EXEcutable), and table.bin. To run the programs, just put them in the same folder as a JAPANESE DECOMPRESSED ROM and double-click them. The ROM must be named zelmujka.z64. ovlnames.exe needs the table.bin to generate the filenames. The scene/map extractor will in addition to the .zscene and .zmap files make a text document called romoffsets.txt, and ovlnames.exe will make ovlromoffsets.txt.

Happy birthday, old friend.

Upped the percussion, and made what's supposed to be a timpani actually be a timpani! I think this is how it will sound in the finished mod now. If anybody has suggestions/ideas for this mod, I'm accepting them. It's not that I don't have things in mind, but I want to know what anybody here can come up with. There will be more kinds of modifications than previously listed. For example, I'm going to need to get rid of the checks in the Running Man so that he's in the field from the get go.

Did it myself with DeathBasket's InstEd.

Violet (Vio) Link from Four swords/Adventures, that is. My goal is for it to be a project that deals with adult themes, like Tingle's Adventure would have. Well, I don't know the direction that one would have taken. I just skimmed the topic about it only after it was cancelled. This is supposed to be very whim-driven like Conker's Bad Fur Day, but within the confines of Ocarina's story. In other words, I don't intend on any massive alterations to the game's events; just to give them a facelift and a new script. You play as Vio, and he encounters characters from his timeline branch, as well as others. From his are Shadow Link and Vaati. In fact, I'll tell you now that those two are going to replace Kotake and Koume. When they combine, they form a villain from another (Zelda) game that I won't reveal. Dark Link will be replaced with Shadow Link as well, but his more, well, shadow-like form. You'll know what I mean if you look at the manga. So basically, no efforts whatsoever will be made to change the plot of the game. The attraction is clever overhauls of what Nintendo laid down. There will be model replacements, modified text, a different overworld track, which will be the Lake Hylia tune from Four Swords Adventures, overworld obstacles, and tweaked dungeon layouts. What's new and exciting about this mod's approach is finding the most outrageous outward replacements for what's already there. If a character is already female, but will be a male character here, he will still have the female sounds, etc. It seems lazy, but this is all meant to be something of a mindfuck. The only help I need right now is somebody that's good at making MIDI imports sound amazing (correct tempo and instrument assignment) and can make them loop properly to do something about that Lake Hylia FSA music over Hyrule Field, and possibly other tracks at a later time. Any takers?

Flotonic got that from what I believe to be an actor table, for the lack of a better descriptor, at 0x5A610. The entries look like: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 E0 00 20 00 00 32 78 F0 00 32 81 10 E0 00 20 00 00 32 64 10 00 32 78 F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 E0 00 C1 60 00 32 81 10 00 32 8E A0 E0 00 C0 00 00 32 8E A0 00 32 C1 10 ... Each entry is 0x18 bytes long, and as you can see, there are null entries; 0x00, 0x02, 0x03, 0x04, and 0x05 in the portion above. There are a total of 0x87 entries in this table. In entry 0x01, and all for that matter, it is unknown what purpose the first four bytes serve, but the next eight are the absolute start and end offsets of the ASM for the actor. The next four bytes are again unknown. The last eight bytes in an entry are the start and end offsets of the model file that the actor uses. Actors can share the same model file, and for that very reason, I have wrote a program to list which actors use the same model file. Here is the result: Model file 00326410 003278F0 used by 0x01 Model file 00328EA0 0032C110 used by 0x06 0x07 0x17 0x1D 0x27 Model file 0032CEC0 0032DD10 used by 0x08 0x09 Model file 0032EC50 0032EE30 used by 0x0A 0x0B Model file 0032FB50 0032FE30 used by 0x0C Model file 00330460 00330910 used by 0x0D Model file 00330F00 00331940 used by 0x0E Model file 003326A0 00333EC0 used by 0x0F Model file 00334C70 00337240 used by 0x10 Model file 00337FC0 00339250 used by 0x11 0x22 0x38 0x3A 0x84 Model file 00339F60 0033B180 used by 0x12 Model file 0033BBD0 0033CDF0 used by 0x13 Model file 0033D610 0033E8C0 used by 0x14 0x2B Model file 0033F000 0033FE80 used by 0x15 Model file 00340880 003419E0 used by 0x16 Model file 00343040 00343680 used by 0x18 0x21 Model file 00343F70 00344A10 used by 0x19 Model file 003451E0 003454E0 used by 0x1A Model file 00345B40 0034DD20 used by 0x1B Model file 0034E770 0034EC80 used by 0x1C Model file 00350220 00352440 used by 0x1E Model file 00352CE0 00353300 used by 0x1F Model file 00353BB0 003547A0 used by 0x20 Model file 00356530 00356980 used by 0x23 Model file 003573A0 003584C0 used by 0x24 Model file 003593B0 00359F20 used by 0x25 0x68 Model file 0035A5E0 0035B9D0 used by 0x26 Model file 0035C550 0035CA80 used by 0x28 Model file 0035D510 0035DA00 used by 0x29 Model file 0035F0E0 003602C0 used by 0x2C Model file 00360A30 00360F40 used by 0x2D Model file 00361670 003625C0 used by 0x2E Model file 00362C50 00363160 used by 0x2F Model file 003638C0 00364300 used by 0x30 Model file 00364C00 00364F10 used by 0x31 Model file 003659B0 00366030 used by 0x32 Model file 00366D60 0036A8D0 used by 0x33 Model file 0036AEE0 0036D020 used by 0x34 Model file 0036DF90 0036E1D0 used by 0x35 Model file 0036ED60 00372790 used by 0x36 Model file 003733E0 003740B0 used by 0x37 Model file 00375510 00376460 used by 0x39 Model file 00377F80 0037A3F0 used by 0x3B Model file 0037ADD0 0037C540 used by 0x3C Model file 0037D180 0037D490 used by 0x3D Model file 0037D9D0 0037F720 used by 0x3E 0x42 Model file 003803A0 003812C0 used by 0x3F Model file 00381E00 00385640 used by 0x40 Model file 003863B0 003889D0 used by 0x41 Model file 0038A350 0038ADF0 used by 0x43 Model file 0038BBA0 0038C5F0 used by 0x44 Model file 0038D070 0038DE00 used by 0x45 Model file 0038E990 0038EE60 used by 0x46 Model file 0038F710 0038F900 used by 0x47 Model file 003903D0 00391D30 used by 0x48 Model file 00392440 003928D0 used by 0x49 Model file 003930A0 00394280 used by 0x4A Model file 00394670 00395BB0 used by 0x4B Model file 003960F0 003965B0 used by 0x4C Model file 00397040 003981F0 used by 0x4D Model file 00398BC0 0039FF20 used by 0x4E Model file 003A0D60 003A2290 used by 0x4F Model file 003A2440 003A2990 used by 0x50 Model file 003A33D0 003A37E0 used by 0x51 Model file 003A4320 003A5550 used by 0x52 Model file 003A5BE0 003A70F0 used by 0x53 Model file 003A77A0 003AA920 used by 0x54 Model file 003AB030 003AEE20 used by 0x55 Model file 003AF700 003B2350 used by 0x56 Model file 003B2D90 003B3EB0 used by 0x57 Model file 003B46A0 003B4790 used by 0x58 Model file 003B5340 003B5CF0 used by 0x59 Model file 003B6BF0 003B7160 used by 0x5A Model file 003B78D0 003B7B80 used by 0x5B Model file 003B8860 003B8BD0 used by 0x5C Model file 003B9A70 003BA030 used by 0x5D Model file 003BAEA0 003BBF60 used by 0x5E Model file 003BCA90 003BCD60 used by 0x5F Model file 003BD9A0 003C11D0 used by 0x60 Model file 003C1BA0 003CADF0 used by 0x61 Model file 003CB890 003CC9E0 used by 0x62 Model file 003CD6E0 003CF3A0 used by 0x63 Model file 003CFAF0 003D0500 used by 0x64 Model file 003D11E0 003D1690 used by 0x65 Model file 003D2580 003D2AC0 used by 0x66 Model file 003D3930 003D3E20 used by 0x67 Model file 003D4E90 003D5020 used by 0x69 Model file 003D5F30 003D67C0 used by 0x6B Model file 003D7040 003D7240 used by 0x6C Model file 003D7770 003D7A70 used by 0x6D Model file 003D80C0 003D8720 used by 0x6E Model file 003D9100 003DB460 used by 0x6F Model file 003DBF40 003DC310 used by 0x70 Model file 003DCD50 003DE000 used by 0x71 Model file 003DEE60 003E0930 used by 0x72 Model file 003E12D0 003E1690 used by 0x73 Model file 003E1CD0 003E1EE0 used by 0x74 Model file 003E2960 003E43A0 used by 0x75 Model file 003E5350 003E54C0 used by 0x77 Model file 003E5F30 003EB4E0 used by 0x78 Model file 003EBE60 003F83F0 used by 0x79 Model file 003F8CC0 003F9E50 used by 0x7A Model file 003FA4B0 003FEAE0 used by 0x7B 0x7D Model file 003FF250 00402640 used by 0x7C Model file 00403BF0 00404220 used by 0x7E Model file 00404F40 00406B40 used by 0x7F Model file 00407080 00409990 used by 0x80 Model file 0040A1C0 0040B3F0 used by 0x81 Model file 0040BBA0 0040C5A0 used by 0x82 Model file 0040D290 00412730 used by 0x83 Model file 00413FA0 00414BA0 used by 0x85 Model file 00415060 00415D90 used by 0x86

EVERY ONE OF THESE USES ITS OWN UNIQUE PALETTE OF 16 COLORS. YES, INCLUDING THE BLANK SLOTS. INFO BELOW ON ROM LOCATIONS. These textures are 4bpp CI, most are 32x32 in dimensions, but some are 24x24. The palette, consisting of 16 colors, follows immediately after the color index portion. The devs threw in extra bytes to throw you off, so you can't immediately pick a texture by its "number" (first row being 0x00 - 0x0F, second being 0x10 - 0x1F, etc.) So what you have to do to compensate for these extra bytes is use these notes: From the wrapped gift (very first texture in the top left) to the bowl of soup (first actual texture of row two), you CAN use the hex numbering scheme like so: Multiply the texture number by 0x220 and add the product to 0x1CC310. Soup example: 0x11 * 0x220 + 0x1CC310 = 0x1CE730 From the bread (immediate right of the soup) to the silver key (first actual texture of row five), you must count in hex starting back at 0x00! It's not too bad, though, because if you understand hex, you know that the texture immediately below is 0x10, then 0x20 below that, etc. Due to the aforementioned extra bytes, you multiply by 0x240 this time. The offset you're adding to is also different, 0x1CE970 this time. Yoshi cookie example: 0x28 * 0x240 + 0x1CE970 = 0x1D4370 From the plain gold key (immediate right of silver key) to the red orb, you multiply the texture number, (yes, the gold key is 0x00, it's always relative) by 0x220. Add to 0x1D5550. Frying Pan example: 0x14 * 0x220 + 0x1D5550 = 0x1D7FD0 I think you get how to set up the formula now, so from here on out I'll just list the starting (0x00) and ending texture, the bytes to skip (multiply the texture number) by, and the base offset you add to. Toad Doll (immediate right of red orb) to brown key (immediate right of scarf): 0x220, 0x1D9DB0 Sky blue key (immediate right of brown key) to umbrella (directly below red orb): 0x220, 0x1DAED0 Pink key (immediately right of umbrella) to Third Degree Card (looks like a flag with 3 stars and is surrounded by yellow): 0x220, 0x1DBFF0 Fourth Degree Card (immediate right of Third Degree Card) to green signature (immediate right of casette tape): 0x220, 0x1DD110 Hand bag (immediate right of green signature) to white envelope: 0x220, 0x1DE230 Brown envelope (immediate right of white envelope) to blank texture three rows above bottom left corner of the image: 0x240, 0x1DEF10 Start of gloved pointer finger frames to star piece counter icon (immediate left of hammer three rows above bottom right corner): 0x140, 0x1F8AD0 IMPORTANT NOTE! These 14 (0x0E) textures are 24x24 in dimensions, fit inside the top left corners of 32x32 spaces in the image. Wooden hammer (three rows above the bottom right corner of the image) to eyes-closed heart: 0x240, 0x1F9C50 Eyes-open heart (immediate right of eyes-closed heart) to open-mouth flower: 0x220, 0x1FAE30 Spinning coin frame one (immediate right of mouth-open flower) to spinning coin frame ten): 0x140, 1FB8D0 THESE TEN TEXTURES ARE 24x24, again fit inside 32x32 spaces in the image. Bright glowing star piece (immediate right of final spinning coin) to regular-lit star piece: 0x220, 0x1FC710 Last eleven textures in the image: 0x140, 0x1FCD70 THESE ARE 24x24. CLICK HERE TO GET GEDECOMPRESSOR, A ROM TOOL CAPABLE OF EXTRACTING AND DECOMPRESSING THE YAY0 FILES IN PAPER MARIO. CAN'T RECOMPRESS, SADLY. So yeah, the icon/animated textures I displayed for you are all before the compressed parts of the rom. I wrote a converter for them and had to literally rebuild it each time I ran into one of those road blocks that the devs threw in. Maybe this will get people interested. Help documenting stuff welcome.

I have too many unfinished piano videos. *Sigh.*

Any sounds that can't be found for Mario in sound libraries were done by Kumiko Watanabe. I can't find the official statement confirming this yet, but everywhere I look says so. Check the folder again. "betamario64.wav" is my attempt to recreate Mario's jump sounds with my voice. The second one, if you compare it to the actual beta footage, is almost identical. I did those in 2010.

They can be RL or animated, fandom-related or just anything. Just nothing that breaks the ToS here, obviously. I have one. I'd suggest spoiler tagging ones that may offend purists. This would definitely cause an uproar among half of the Zelda fandom. XD It's an animation. The models are not mine. They belong to marukopouro. Don't ask for a download.