Twili

I play it strangely at first on purpose, but normal the second time around. Here's a cover I actually finished all the way.

This is a teaser for some modifications I'm making to Majora's Mask. Here I made Zora Link dance to show off his Hylian skin tone, which isn't finished yet.

I'm not giving the download link directly, but if you google ctr_sdk_4_2_8 you will find a certain pastebin link... And yes, I created a topic about the SDK on GBAtemp.

The above is from the readme html document. We know that using the SDK is illegal if you're not a registered developer, but what if it spurred progress of an emulator that could finally run commercial games? Would you use an emulator that referred to an official SDK to get things finished quicker?

http://gbatemp.net/threads/release-3ds_ctr_decryptor-void.370684/ All you have to do is follow the steps in that topic, but you still need a 4.1-4.5 firmware 3DS/XL. You wind up with a xorpad that you xor with the corresponding part of the encrypted ROM to get decrypted data, then you extract it with ctrtool. If you don't have the right firmware, you're not out of luck as long as you know someone that has the xorpads. I was lucky enough to quickly get in contact with such a person.

The Arwing explosion and Twinrova's fire attack have never been emulated correctly. Majora's Mask catching fire also isn't emulated correctly. Hopefully that will be fixed this time.

I've learned more since I made the video, and now models won't be missing any parts. Download all of the models I was able to convert here: http://www.mediafire.com/download/plcefyev2rdb827/ActorCommonOBJs.rar And here: http://www.mediafire.com/download/l6ld0ccbi9gsviv/Demo8OBJs.rar They still lack textures, because I don't understand the texture format yet. But you can give them funky custom textures if you want to use them for anything. Here's some previews of the characters only: Link model comparison (gameplay versus cutscenes): The cutscene model has two sets of hands; open and closed. Princess model comparison (Hilda versus Zelda): Ravio model comparison (hood down (most of the game) versus hood up): Irene:

West Clock Town uses a separate object for most of its geometry, not an external texture file, yes. I don't know exactly which one at the moment.

At 0xC58BA0 in a decompressed (U) [!] Majora's Mask ROM is a table for external texture files. Look at the second byte of the header command beginning with 0x11 in a scene file. If it's greater than 00, multiply it by 8 and add it to 0xC58BA0. That offset will show you to the start and end offset (XXXXXXXX YYYYYYYY) of the external texture file that the map uses. Look in the display lists for G_SETTIMG (0xFD) commands with pointers that don't use bank 02 or 03. They will point to within the external texture file.

Also, these Python scripts by smealum are supposed to convert from BCH to OBJ, but the files from ALBW don't quite follow the same format: https://gist.github.com/smealum/9394125 So it's pretty much a dead end until it can be figured out.

Only these models. No maps.

http://www.mediafire.com/download/z0rj1kemar8bq21/ActorCommonBCHs.rar Join me in figuring out the model format for A Link Between Worlds! These were extracted from ActorCommon.szs, so they're the models used in many places, such as Link. Here's what I know so far about the format, using Link's model (055.bch) as an example: === HEADER 0x0: Magic word "BCH" (null-terminated.) 0x4: Unknown, is set to 2121E1A2 in every file. 0x8: Chunk 1 pointer. (44000000) Needs to be word-swapped. 0xC: Chunk 2 pointer. (643A0000) Needs to be word-swapped. 0x10: Chunk 3 pointer. (A03E0000) Needs to be word-swapped. 0x14: Chunk 4 pointer. (00780000) Needs to be word-swapped. 0x18: Chunk 5 pointer. (00900300) Needs to be word-swapped. 0x1C: Chunk 6 pointer. (8C250400) Needs to be word-swapped. 0x20: Chunk 1 size. (203A0000) Needs to be word-swapped. 0x24: Chunk 2 size. (30040000) Needs to be word-swapped. 0x28: Chunk 3 size. (20390000) Needs to be word-swapped. 0x2C: Unknown. (28180300) Needs to be word-swapped. 0x30: Also unknown. (A4950000) Needs to be word-swapped. You would think that these are the sizes for chunks 4 and 5, but adding them to the pointers results in them running past the start of the next chunk. 0x34: Chunk 6 size. Needs to be word-swapped. (CC0B0000) 0x38: Another unknown value (D0010000), but is as big as the half-word at 0x42 multiplied by 4. This applies to every file. Needs to be word-swapped. 0x3C: Reserved? Set to 00000000 in every file. 0x40: A half-word that needs to be byte-swapped. 0100 (0001 byte-swapped) in every file except 065.bch, where it is 0000. 0x42: The half-word that when multiplied by 4 equals the value at 0x38, and needs to be byte-swapped first of course. (7400) === Chunk 2 will be mentioned first because it's used by others. It's purely null-terminated strings that aren't aligned. Excerpt: 2@DefaultShader-s2-nl.3@DefaultShader-nl.LarmA_jnt.LarmB_jnt.Lclotch_jnt.Link_model. === Chunk 1 contains the skeleton, I assume? If you search for pointers relative to the start of Chunk 2 in your hex editor, such as 3D000000 (0000003D word-swapped) which goes to "Lclotch_jnt", you will find them. I literally don't have any more of a clue as to the format of this chunk, as it's extremely convoluted, like the others! === Chunk 3 I know for certain loads indices and points to textures. Examples... 00EC0200 27020F00 08040000 28020F00 The above is at 0x54C0 (absolute.) Again, everything needs to be word-swapped. The first word is a relative pointer into Chunk 4. The third word is the size of the indices data requested, so divide this by 2 if you wish for the amount of indices. I don't know for certain what purpose words two and four serve. 80100000 9D000F00 0D000000 9E000F00 The above is at 0x67E0 (absolute.) Word-swapping needed. I only know that the first word is a relative pointer into Chunk 4. This is for a texture. Each texture seems to be pointed to three times for some reason. That's all that I know about Chunk 3 now. No determining how the data is pointed to for specific model parts yet. === Chunk 4 contains textures and indices. That's all I've got to say. === Chunk 5 is the vertices, normals, and texture coordinates. Nothing else about it for now. === Chunk 6 I have no idea about. === I hope that somebody can make use of these notes, which are incredibly lacking.

https://mega.co.nz/#F!pV5hyCbI!nT_j4aeXqWVx5aeBPLGMew These are .wav outputs directly from vgmstream. I have left the filenames intact, only prefixing them with numbers by the order that they're heard in the game. I skipped through a 100% playthrough of the game on YouTube to do so. The link takes you to 10 zip archives. I could upload them individually if anybody wants me to, though.

I think flowers covered Link. The video is too blurry to be 100% sure, but...?

Ah, ok. That's her actual number of limbs, though. Just saying.

I converted her hierarchy and all of her animations about three years ago... http://www.mediafire.com/download/426ewwvbzv5yx11/arianime.zobj Video: https://www.youtube.com/watch?v=dHH8NAGFnlE Can't play it embedded because Flotonic requested that embedding be disabled on it. The arm you see at her feet in the video is a Utility of Time rendering bug. Also, facial animations seen were achieved through clever video editing, but the file above is 100% legit with everything converted.

00DE 00D5 Tentacle from inside Lord Jabu-Jabu - 0000 = Reddish brown - 0001 = Green - 0002 = Grayish blue with some red - 0003+ = Already dead 00DF 00D5 Jabu-Jabu Electrified Tentacle - 0000 = Reddish brown - 0001 = Green - 0002 = Grayish blue with some red - 0003 = Corrupt textures, still visible and works - 0004 = Dark brownish - 0005+ = Blackish gray 0xD5 is object_bxa.

Bump because these are relevant to the 3DS in general, and this ought to be the technical discussion thread for the 3DS: https://github.com/bunnei/citra <- Real, working 3DS emulator. Only supports homebrew games. (For now?) EDIT: This site makes nightly builds, apparently, so you don't have to compile it: http://www.emucr.com/2014/04/citra-git-20140425.html http://pastebin.com/WueL0LnL <- File list for A Link Between Worlds.

He posted this on Z64: Here's the source: http://dl.dropboxusercontent.com/u/336940/Software/Hextator%27s%20Doc/Media/Games/Reverse%20Engineering/Console/N64/Zelda/Ocarina%20of%20Time/NPC%20Killing/folDIR.html

http://irc.lc/badnik/zelda

N3DSCmbViewer source?

http://facepunch.com/showthread.php?t=1380319

I understand vertex skinning perfectly now! There are three possible values for "Unknown (2)" in the prms chunk: Within any sepd in link.cmb: -- PrmsChunk -- Unknown (1): 0x1, Unknown (2): 0x0 Index count: 0x1, Index offset: 0x18 Prm chunk offset: 0x1C Index #0: 0x7 Within the first sepd in stalfos.cmb: -- PrmsChunk -- Unknown (1): 0x1, Unknown (2): 0x1 Index count: 0x9, Index offset: 0x18 Prm chunk offset: 0x2C Index #0: 0xE Index #1: 0xC Index #2: 0x2 Index #3: 0xF Index #4: 0x8 Index #5: 0xA Index #6: 0x5 Index #7: 0x4 Index #8: 0x6 Within the first sepd in babydodongo.cmb: -- 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 As you can see, Unknown (2) will be set to 0, 1, or 2. 0 means all vertices indexed inherit the properties of a single bone ID. 1 means on a per-vertex basis to look up which bone to use the properties of. When Unknown (2) is set to this, there will always be more than one "Index" value (bone ID). The indices for drawing triangles will serve two purposes in this case. The first is still indexing which vertices to draw the triangle between. The second is they also serve as indices into "Unknown array 3" in the vatr chunk. Unknown array 3 consists of single-byte values that look up which bone ID to use from the prms chunk. For example, if the byte in Unknown array 3 was 03 in the Stalfos, for the prms chunk above that particular vertex (index value into Unknown array 3) would inherit the properties of bone ID 0xF. 2 means the same as 1, except the vertices DO NOT inherit the translations of their bones, they are only "mapped" to them. (Scaling and rotation only.) So just be sure when reading sepd chunks that the third unknown array is now used. Also, I would like a new build that I can download if this works, possibly with bone selection and the ability to modify the rotation values of them so that it's possible to see that it's working properly. Still no reading of the animations themselves, but we're so close now!

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