F3DEX to Fast3D conversion

[xdaniel]

First of all: great video, it's really awesome to see this. Next, however: I'm apparently too stupid to correctly insert both, map and scene files. All I'm getting is a crash once I'm trying to load the level from the Map Select... Thus, another question: How do I do this correctly? <.<  God, I'm feeling kinda like a n00b right now...

[spinout]

1) Goto 0x35D0000 in ROM
2) Copy/Paste scene data into ROM at this offset
4) Record end offset
5) Paste map at end of scene, recording start/end offset
6) Goto beggining of scene in ROM, look for "map offs" on ascii side
7) Write map offsets there
8) Goto 0xBA1434 in ROM, write scene offsets
9) ???
10) Profit!!!

Note that some areas are too big for OoT's engine and will not load, try testing with something like 0xC, 0x16, 0x5. Also, xdaniel, I've noticed some missing geometry, ex 50% of the stuff in bob-omb's battlefeild. You might want to look into this, I don't know if the error existed before my additions or not.

Edit: I think I'll add a option to insert the map/scene into ROM.

[xdaniel]

Positive: Profit got! http://www.youtube.com/watch?v=8DWkssKoV1s

Now for the negative: Many levels I've tried just won't convert at all, with the converter either crashing or just freezing without explanation. For example, the last messages 0x05, Bob-Omb's Battlefield, shows before the converter freezes is the following:

VtxCount 570 ColVtxCount 0
ColType: 0x0000 ZTriOffset 0x0 TriCount 378 ColTriCount 378
ColType: 0x0005 ZTriOffset 0x17A0 TriCount 2 ColTriCount 380
ColType: 0x000B ZTriOffset 0x17C0 TriCount 55 ColTriCount 435
ColType: 0x0013 ZTriOffset 0x1B30 TriCount 5 ColTriCount 440
ColType: 0x0014 ZTriOffset 0x1B80 TriCount 62 ColTriCount 502
ColType: 0x0015 ZTriOffset 0x1F60 TriCount 167 ColTriCount 669
ColType: 0x0028 ZTriOffset 0x29D0 TriCount 198 ColTriCount 867
ColType: 0x0029 ZTriOffset 0x3630 TriCount 141 ColTriCount 1008
ColType: 0x002A ZTriOffset 0x3F00 TriCount 43 ColTriCount 1051

Nothing out of the ordinary, I think. Trying to debug it doesn't really yield any obvious results, no matter what level - hell I'm not even getting function names and line numbers in the call stack like usual, and yeah, debugging symbols are enabled. When it works, it's a really awesome piece of code you've added there, but this behaviour is rather weird.

Maybe it's just my compiler/setup, I dunno. I'll see if I can try it under Linux tomorrow or so...

[spinout]

Easy fix, I think.

...
ColType: 0x0029 ZTriOffset 0x3630 TriCount 141 ColTriCount 1008
ColType: 0x002A ZTriOffset 0x3F00 TriCount 43 ColTriCount 1051

ZTriOffset is the address within ColTriBuffer.
somewhere in my code:
   ColVtxBuffer = (unsigned char *) malloc (0x4000);
   ColTriBuffer = (unsigned char *) malloc (0x4000);

tl;dr buffer overflow.

Edit: Made each buffer 1 MB, I doubt this will ever happen again.

Edit 2: Hmm, it still hangs up on Bob-Omb's battlefeild. Looking into this further...

Edit 3: Well, I found out why it was hanging ( < instead of <= ), and Bob-Omb's battlefeild works now, and somehow the mesh that wasn't there now is. I'm gonna take another look at geometrymode, vertex colors seem to be enabled where they shouldn't be. Oh, and I added a option that automatically imports to ROM, so that makes testing 10x faster.

[Zeth]

Wow the progress of this is going really great guys! Keep up the good work!
I'm definitely looking forward to trying this converter/importer when you guys finish it. Also, a bit off topic but, both Medli and I have been looking into more of how the audio works in Ocarina of Time, with the hopes of being able to import music a bit more better then the current method, also with the possibility of not having to replace music.

[xdaniel]

Fixed the annoying grey grass:



case F3D_MOVEMEM:
   if(((RAMSegment[Seg].Data[Offset + 1] >= 0x86) && (RAMSegment[Seg].Data[Offset + 1] <= 0x94)) && (RAMSegment[Seg].Data[Offset + 4] == 0x07)) {
      int lightno = (RAMSegment[Seg].Data[Offset + 1] / 2) - 0x42;
      lightno = 0x06 + (lightno * 0x03);

      ZMapBuffer[TargetOffset] = F3DEX2_MOVEMEM;
      ZMapBuffer[TargetOffset + 1] = 0x08;
      ZMapBuffer[TargetOffset + 2] = lightno;
      ZMapBuffer[TargetOffset + 3] = 0x0A;

      ZMapBuffer[TargetOffset + 4] = 0x03;
      ZMapBuffer[TargetOffset + 5] = ((w1 + ZMAP_HEADERGAP) & 0x00FF0000) >> 16;
      ZMapBuffer[TargetOffset + 6] = ((w1 + ZMAP_HEADERGAP) & 0x0000FF00) >> 8;
      ZMapBuffer[TargetOffset + 7] = ((w1 + ZMAP_HEADERGAP) & 0x000000FF);
   } else {
      ZMapBuffer[TargetOffset] = F3DEX2_SPNOOP;
   }

   #ifdef DEBUG
   printf("- Found F3D_MOVEMEM at 0x%06X...\t\tNG\n", Offset);
   #endif
   break;

Not complete, thus tagged NG, but enough for SM64.

EDIT: Also fixed that damn GEOMETRYMODE, forgot that some flags also differ between Ucodes, especially those that control frontface/backface culling:

Code:

case F3D_SETGEOMETRYMODE:
ZMapBuffer[TargetOffset] = F3DEX2_GEOMETRYMODE;

// convert parameters
if(w1 & 0x00000002) { // TEXTURE_ENABLE
w1 &= ~0x00000002;
w1 |= 0x00000000;
}
if(w1 & 0x00000200) { // SHADING_SMOOTH
w1 &= ~0x00000200;
w1 |= 0x00200000;
}
if(w1 & 0x00001000) { // CULL_FRONT
w1 &= ~0x00001000;
w1 |= 0x00000200;
}
if(w1 & 0x00002000) { // CULL_BACK
w1 &= ~0x00002000;
w1 |= 0x00000400;
}
if(w1 & 0x00003000) { // CULL_BOTH
w1 &= ~0x00003000;
w1 |= 0x00000600;
}
if(w1 & 0x00000000) { // CLIPPING
w1 &= ~0x00000000;
w1 |= 0x00800000;
}

ZMapBuffer[TargetOffset + 1] = 0xFF;
ZMapBuffer[TargetOffset + 2] = 0xFF;
ZMapBuffer[TargetOffset + 3] = 0xFF;

ZMapBuffer[TargetOffset + 4] = 0x00;
ZMapBuffer[TargetOffset + 5] = (w1 & 0x00FF0000) >> 16;
ZMapBuffer[TargetOffset + 6] = (w1 & 0x0000FF00) >> 8;
ZMapBuffer[TargetOffset + 7] = (w1 & 0x000000FF);

#ifdef DEBUG
printf("- Found F3D_SETGEOMETRYMODE at 0x%06X...\tOK\n", Offset);
#endif
break;

case F3D_CLEARGEOMETRYMODE:
ZMapBuffer[TargetOffset] = F3DEX2_GEOMETRYMODE;

// convert parameters
if(w1 & 0x00000002) { // TEXTURE_ENABLE
w1 &= ~0x00000002;
w1 |= 0x00000000;
}
if(w1 & 0x00000200) { // SHADING_SMOOTH
w1 &= ~0x00000200;
w1 |= 0x00200000;
}
if(w1 & 0x00001000) { // CULL_FRONT
w1 &= ~0x00001000;
w1 |= 0x00000200;
}
if(w1 & 0x00002000) { // CULL_BACK
w1 &= ~0x00002000;
w1 |= 0x00000400;
}
if(w1 & 0x00003000) { // CULL_BOTH
w1 &= ~0x00003000;
w1 |= 0x00000600;
}
if(w1 & 0x00000000) { // CLIPPING
w1 &= ~0x00000000;
w1 |= 0x00800000;
}

ZMapBuffer[TargetOffset + 1] = ~(w1 & 0x00FF0000) >> 16;
ZMapBuffer[TargetOffset + 2] = ~(w1 & 0x0000FF00) >> 8;
ZMapBuffer[TargetOffset + 3] = ~(w1 & 0x000000FF);

#ifdef DEBUG
printf("- Found F3D_CLEARGEOMETRYMODE at 0x%06X...\tOK\n", Offset);
#endif
break;

The ANDs and ORs could probably be done better, but it's working for the moment.

EDIT 2: Also fixed some data alignment issues that caused ex. most of Battlefield's textures to be read badly (off by a few bytes).

[SirTopHat]

It seems ironic that SM64 areas are too big for OoT.

[Zeth]

Well SM64 was one of the first games made for the N64, it was the first real 3D game Nintendo has ever made, they later learned they could scaled down the models to include more and help performance, as seen in later games. The joys of developers work arounds.

[SirTopHat]

I didn't think the scale of a model made any difference as far as performance if the player and environment are on the same scale.

[Arcaith]

Think about it carefully man. If you have a list of co-ordinates for a vertex like 50,000 - 34,000 - 80,000, then if you strip it down to 50 - 34 - 80, it's going to take up less space on the cart, and less in RAM. Slightly extreme example, but you get the idea.

[SirTopHat]

well I didn't think it would take a processor much more time to handle larger numbers like that.

[Arcaith]

Performance doesn't just mean speed. However, you must consider the fact that OOT natively only draws the polygons that are visible in the view. To do that, it has to load segments of the overall model into RAM, but it also has to clear the RAM again afterwards. If the camera is being constantly rotated (as an example) then it's being loaded and cleared progressively constantly. With smaller numbers, there's more free RAM to work with for that process and it takes less time to clear blocks that are no longer needed.

[xdaniel]

http://z64.spinout182.com/index.php?topic=37.0 ?

[SirTopHat]

I see, Arcaith. On emulators it doesn't do that though?

[xdaniel]

http://www.youtube.com/watch?v=Wd7OYfBgNlg

NOT the build posted in the above thread, the one in the video had some more fixes and additions done to it.