Twili

Wow. This is VERY good news, were there to be a beta restoration project.

You may see it loaded in the future.

I contacted JayTheHam some time last month to ask him where the files for it were, and this was his reply: If you've read the Zelda Chaos page, you would know that the map file for it is missing. Well, I now know that it is. That page claimed that it was "not properly compiled(or in a different format)." I tried to load the map that was in the directory in BMDview2, and nothing showed up. So I opened it in a hex editor and saw lots of text. Then I opened it as a text document and it was clear that this was a Maya file: <HeaderInfo> map test_R00_siroroom project projectMapTool generator Maya user DummyUser version 1.31 date 2002/07/19 time 15:20 num_define 2 define_tag GroupDefine define_tag PolygonDefine </HeaderInfo> The spacing of the above text is unfortunately not preserved in this post. I converted the polygons by hand (making a few mistakes here and there) and loaded part of this in UoT: Then the rest of it: At this moment I realized that the map for the forest no longer exists. I took a peek at the .dzb and .dzr files JayTheHam mentioned, and the .dzb file was the collision. I know this because I figured out enough of the format for it to get the triangles converted (with a program!). The vertex coordinates were single precision floats, so I had to write a function that converted them to decimal (like the IEEE-754 calculator online). This was the result: See the triangles that form squares under those mushrooms? Those are for their shadows. This is proof that the collision file is one hundred percent identical to the map file (geometry-wise), because nothing is optimized.

I believe you are right, xdaniel, about the second and third halfwords in the animation/path entries being the start and end frame.

0x27E5308 in the debug rom (0xF308 into spot00_scene or 0xD18 into its cutscene at 0xE5F0): 00 00 00 0A 00 00 00 13 00 00 00 0A = Marker. 00 00 00 13 = Number of paths for Link (hex). The entries are immediately after, 0x30 in length each: 00 01 00 00 01 90 94 3A 00 00 00 00 00 00 00 FC 00 00 00 00 00 00 07 3A FF FF FF FE 00 00 00 00 00 00 05 65 BF 22 8F 5C 00 00 00 00 3F 22 8F 5C 00 01 = Current action. Zeth made a list of these that was to be redone. 00 00 = Starting frame for path. 01 90 = Ending frame for path. 94 3A 00 00 00 00 = Unknown. 00 00 00 FC = X coordinate of path start vertex. 00 00 00 00 = Y coordinate of path start vertex. 00 00 07 3A = Z coordinate of path start vertex. FF FF FF FE = X coordinate of path end vertex. 00 00 00 00 = Y coordinate of path end vertex. 00 00 05 65 = Z coordinate of path end vertex. BF 22 8F 5C 00 00 00 00 3F 22 8F 5C = Appears to be a vertex normal for the path, single precision floats. Changing them doesn't have any obvious effect. There is a table for those actions that I discovered at 0xC239B8 in the rom. You can see that the last 4 bytes are always 00 00 00 00, a "virtual offset", or a gameplay_keep pointer to an animation header for Link. I put Zeth's list against these: 00 00 00 00 00 00 00 00 | 00 does nothing FF 00 00 00 80 85 15 A4 | 01 Normal still stance 02 00 00 00 04 00 27 90 | 02 Looks back real quick 00 00 00 00 00 00 00 00 | 03 Runs like hell (Beta and broken) 00 00 00 00 00 00 00 00 | 04 Normal still stance 03 00 00 00 04 00 27 40 | 05 Surprised 00 00 00 00 00 00 00 00 | 06 Froze x.x 00 00 00 00 00 00 00 00 | 07 does nothing FF 00 00 00 80 85 15 A4 | 08 stand still 02 00 00 00 04 00 27 78 | 09 turn around surprised FF 00 00 00 80 85 17 88 | 0A walk into warp 03 00 00 00 04 00 28 60 | 0B preparing to warp FF 00 00 00 80 85 18 DC | 0C beta side stance 07 00 00 00 04 00 23 48 | 0D beta holding something 05 00 00 00 04 00 23 50 | 0E got an item 05 00 00 00 04 00 23 58 | 0F got an item reversed? 05 00 00 00 04 00 23 B0 | 10 Getting up from sitting 07 00 00 00 04 00 23 B8 | 11 sitting on the ground FF 00 00 00 80 85 19 EC | 12 pulling mastersword out 02 00 00 00 04 00 27 28 | 13 getting magic from faries 02 00 00 00 04 00 27 38 | 14 Hold shield? o.o 00 00 00 00 00 00 00 00 | 15 freezes link no crash FF 00 00 00 80 85 1B 90 | 16 legs stuck out 03 00 00 00 04 00 27 A8 | 17 Faries blessing? 09 00 00 00 04 00 2D B0 | 18 Link falls forward And more.

Part of the Hyrule Field theme.

Been working on this with Flotonic lately: Also first preview of one for Mario:

The process of converting from the old format is now automated. You just supply the file and the animation offset, then fix the two header pointers after conversion. A "segment" here is actually an X, Y, or Z rotation. The program assumes that the first rotation value will always be 0000 and writes it automatically. The values succeeding "In segment: XX" are the index values for the rotations, not the actual rotations. The program is also "rigged" to only work with the IPL4ROM (the hacked BIOS) right now because Mario's animation headers use ram pointers, and it subtracts 8025F000 from them. Key: 00BA Bone count: 0014 Rotation values: 0001F6E0 Rotation index: 00021704 Gettting static rotations... In segment: 00 In segment: 01 In segment: 02 In segment: 03 In segment: 04 0175 In segment: 05 In segment: 06 In segment: 07 In segment: 08 1011 In segment: 09 In segment: 0A In segment: 0B 0F56 In segment: 0C In segment: 0D In segment: 0E 0E9B In segment: 0F 0D23 In segment: 10 0D24 In segment: 11 0D25 In segment: 12 0179 In segment: 13 017A In segment: 14 017B In segment: 15 In segment: 16 In segment: 17 0178 In segment: 18 In segment: 19 0176 In segment: 1A 0177 In segment: 1B 0D1F In segment: 1C 0D20 In segment: 1D 0D21 In segment: 1E In segment: 1F In segment: 20 In segment: 21 In segment: 22 In segment: 23 In segment: 24 In segment: 25 In segment: 26 In segment: 27 In segment: 28 In segment: 29 0D22 In segment: 2A 0D1C In segment: 2B 0D1D In segment: 2C 0D1E In segment: 2D In segment: 2E In segment: 2F In segment: 30 In segment: 31 In segment: 32 In segment: 33 In segment: 34 In segment: 35 0D26 In segment: 36 In segment: 37 In segment: 38 In segment: 39 In segment: 3A In segment: 3B In segment: 3C In segment: 3D In segment: 3E Getting dynamic rotations... In segment: 00 0001 In segment: 01 00BB In segment: 02 In segment: 03 In segment: 04 In segment: 05 In segment: 06 In segment: 07 0F57 In segment: 08 In segment: 09 In segment: 0A 0E9C In segment: 0B In segment: 0C 0D27 In segment: 0D 0DE1 In segment: 0E In segment: 0F In segment: 10 In segment: 11 In segment: 12 In segment: 13 In segment: 14 In segment: 15 In segment: 16 In segment: 17 In segment: 18 In segment: 19 In segment: 1A In segment: 1B In segment: 1C In segment: 1D In segment: 1E 0464 In segment: 1F 051E In segment: 20 05D8 In segment: 21 In segment: 22 In segment: 23 03AA In segment: 24 017C In segment: 25 0236 In segment: 26 02F0 In segment: 27 In segment: 28 In segment: 29 In segment: 2A In segment: 2B In segment: 2C In segment: 2D In segment: 2E In segment: 2F 0C62 In segment: 30 In segment: 31 In segment: 32 0BA8 In segment: 33 In segment: 34 In segment: 35 In segment: 36 097A In segment: 37 0A34 In segment: 38 0AEE In segment: 39 In segment: 3A In segment: 3B 08C0 In segment: 3C 0692 In segment: 3D 074C In segment: 3E 0806 Building rotation index... Building header...

He uses the depreciated animation format. I converted one of his animations by hand like I did with all of object_human's. 186 frames here. This is where he peeks around the corner of the N logo and waves. Right boot (from Mario's perspective) is not rotated due to a bug present in UoT since SVN R8.

Mario's full hierarchy: Now I completely understand how object hierarchies work from a non-matrix point of view. Let's use our good ol' friend object_oB1 for example: 06|05AA 0000 0000 070A 00000000 07|04E2 0000 0000 0809 00000000 08|0000 0000 0000 FFFF 060008E8 09|0000 0000 0000 FFFF 06000750 0A|0000 0000 0000 FFFF 06000448 This is one of his legs. Here's how it "actually" works: Limb 06's connection type is 070A. We're going to ignore the second byte for now. The first byte says that limb 07 will inherit this limb's translation (1,450 on the X, 0 on the Y, and 0 on the Z). Now we're in limb 07. Its translation is 2,700 on the X, 0 on the Y, and 0 on the Z because it inherited the translation from the previous limb PLUS its translation of 1,250 (1,250 + 1,450 = 2,700). Its connection type is 0809. We're going to ignore the second byte again. As you may have guessed, limb 08 is going to inherit this limb's translation (2,700 on the X, 0 on the Y, and 0 on the Z). Limb 08. Its translation is 2,700 on the X, 0 on the Y, and 0 on the Z because it inherited the translation of the previous limb PLUS its translation of 0 (2,700 + 0 = 2,700). Its connection type is FFFF! This means that we've reached the end of a full connection. Like I said, we're not going to deal with any pushes or pops here because we're doing this from a non-matrix point of view. Here's where the second byte of a connection type comes in. This is the "next limb", the first byte was the "child limb". The next limb will inherit the translation of its grandparent, AKA the limb that is two limbs back in a full connection. Here's how this plays out with object_oB1: I said that limb 06's connection type was 070A. The second byte being 0A means that limb 0A is the next limb. The next limb's translation will be 0 on the X, 0 on the Y, and 0 on the Z because it doesn't have a grandparent. Limb 07's connection type was 0809. The second byte being 09 means that limb 09 is the next limb. The next limb's translation will be 1,450 on the X, 0 on the Y, and 0 on the Z because its grandparent is limb 06. SO! The final translation of all of the limbs will be: 06: X=1,450 Y=0 Z=0 07: X=2,700 Y=0 Z=0 08: X=2,700 Y=0 Z=0 09: X=1,450 Y=0 Z=0 0A: X=0 Y=0 Z=0 Limb 08 has a Display List, 060008E8. This is a brown boot. Limb 09 has a Display List, 06000750. This is a green pant leg. Limb 0A has a Display List, 06000448. This is a green thigh (actually the upper part of the pant leg, but I use thigh/leg and shoulder/forearm for distinction). This is what it looks like translated properly:

This screenshot is apparently taken from the 64DD emulator (not Project Unreality): 「F-ZEROX〠ã¯, ã“ã®ディスクã ã‘ã§ã¯プレイ ã§ãÂÂã¾ã›ん. NINTENDO64ソフト 「F-ZEROX〠ã®カセット ã‚’64本体ã«セットã—ã¦, é›»æºÂを入れ直ã—ã¦ãÂÂã ã•ã„. Could I get a proper translation of this? And did I make any mistake transcribing the text above?

Only UoT has a complete vertex editor for maps and objects (including texture coordinate tweaking), but only in builds pre-animation/hierarchy support. Best one for this would be UoT .90b4.1.

I realized that the image in this post on page 1, the disassembly is from the F-Zero Expansion Kit. OR A1,S3,R0 JAL 0x80757850 OR A2,S6,R0 JAL 0x80747ED0 OR A0,S4,R0 OR A0,V0,R0 JAL <leoOSWritebackDCache> LW A1,0x0000(S6) LW A0,0x0040(SP) LW A1,0x0044(SP) OR A2,S2,R0 OR A3,S4,R0 SW S3,0x0010(SP) JAL <leoOSleoReadWrite+0> SW S7,0x0014(SP) OR A0,S7,R0 OR A1,S1,R0 JAL <leoOSRecvMesg+0> ADDIU A2,R0,0x0001 If you assemble the first six instructions shown and search for them in the EK, you will find them at 0xA39DD0 (you obviously can't assemble a JAL with a label unless you define it first). Identifying these leoOS function calls in the machine code, though, you will discover that they map to 8074BA30, 807560F0, and 80746000. You will never find the functions themselves, because they are internal to the 64DD and Kammedo is reverse engineering them. Now I wonder what LEO stands for... maybe L for Laser.

Because text strings must be word-aligned, the buffer between a message and the next can be used when editing. "エラー：" -> "Error" is most certainly the only extreme case where this works without repointing, though, because of the Shift-JIS deal. The error number will have to be shifted over to prevent the overlap seen here.

Hah, 0x1F428. That's right after the null terminator for the "kanji pointer table" I documented in the topic post.

Ehh... I knew this would happen. Things always go under the wraps when I make a post stating that I'll only edit the topic post, so I had to break my vows. Nobody is going to check the topic post for updates, so... I FOUND THE FONT!!! 0xA0000. Characters are 4-bit I, 16x16. The numbers here are actually 0x4900 bytes into the font, so they're characters 0x92 - 0x9B. Now we just need the text data.

Thanks, but I think I'm going to take a step back from this until I have an adequate understanding of object hierarchies. The limb connections still blow my mind, particularly the type with both a child limb and a next limb. I'm going to get back to documenting the IPLROM and editing the topic post with my discoveries, so you'll see no more unique post IDs from me in here.

Got a whole arm working now.

Amazing how a change in skybox can make a place feel so different.

Watched a how-to video about an hour before, actually.

Not sure about that. Those are the only Display lists that I have been able to convert and view so far. I tried a shoulder and it didn't work.

Mario partially loaded with spinout's skeleton actor.

I successfully converted Mario's head with a hex editor and SM64toZ64. Using Link to test was arbitrary. This is the most difficult part of the whole job. EDIT: Torso converted!