Z64

Please login or register.

Login with username, password and session length
Advanced search  

News:

Check out and improve the wiki!

Pages: [1] 2 3 4

Author Topic: F3DEX to Fast3D conversion  (Read 15455 times)

xdaniel

  • Global Moderator
  • Sr. Member
  • *****
  • Posts: 295
    • ICQ Messenger - 136250978
    • View Profile
F3DEX to Fast3D conversion
« on: January 19, 2010, 12:48:01 AM »

Some random shit I thought of earlier, thinking of a better way for porting ex. Banjo-Kazooie maps to Mario 64...

F3DEX TO FAST3D THEORY:
----------------------

File 1: F3DEX v1 dlist/tex/verts/etc  (ex. BK)
File 2: Fast3D          ""            (ex. SM64)

- load file 1 into buffer
- scan for commands that need changing (VTX etc)
- modify command + insert additional cmds if needed

ex. VTX + TRIx:
ORIGINAL:  24 verts, buffer index 0, offset 0x012800
           -TRIx cmds that use verts 0-24-
         
MODIFIED:  16 verts, buffer index 0, offset 0x012800
           -TRIx cmds that use verts 0-16-
         8 verts, buffer index 0, offset 0x012A00
         -TRIx cmds that use NEW verts 0-8, previously 17-24-

PITFALLS: careful if buffer index NOT 0!
         
- save modified buffer into file 2
- PROFIT!


Some more shit regarding vertex buffer size problems I didn't think of earlier (F3DEX's buffer is 32, F3D's is only 16 vertices or so):

go through file until VTX command
take note of vtx amount to load
if amount < 0x10, go on normally (TRIx etc) - NO CHANGES NEEDED
if amount >= 0x10, calculate remaining vtxs to take care of: (amount - 16) = remaining
    ex. (24 - 16) = 8 thus 8 vtxs remaining
    ex. (8 - 16) = -8 thus no vtxs remaining
go through following TRIx cmds until one refers to vtx ABOVE 16 (= not yet covered by last VTX cmd)
- use cmds before offending cmd as is
- starting from offending cmd, scan following cmds until next VTX or ENDDL for vtx BELOW 16 (= covered by last VTX cmd, but going to be OVERWRITTEN by cmd for vtxs 16-32)
    ex. TRI2 (16, 17, 5), (18, 6, 7) = vtxs 5, 6, 7 of last VTX cmd needed!
- take note of all vtxs found by above, substract 16 from those above 16, resulting in ex.
    5     - 0  = 5
    6     - 0  = 6
    7     - 0  = 7
    16    - 16 = 0
    17    - 16 = 1
    18    - 16 = 2
    19    - 16 = 3
    20    - 16 = 4
    21    - 16 = 5    *
    22    - 16 = 6    *
    23    - 16 = 7    *
    24    - 16 = 8
    25    - 16 = 9
    26    - 16 = 10
    27    - 16 = 11
    28    - 16 = 12
    29    - 16 = 13
    30    - 16 = 14
    31    - 16 = 15
- vtxs marked * exist TWO TIMES, the "real" one (covered by original VTX cmd) and the "fake" one (to be covered by the next VTX cmd)
- PROBLEM: can't have two different vtx with the same number!
- SOLUTION: before each TRIx that refers to a "real" vtx, insert a VTX cmd that restores the vtx data into its original slot, AND insert one afterwards that rerestores the "fake" vtx
- ALSO in this case split TRI2 cmds into TRI1s, makes overlaps less likely, THUS ex.:
    - TRI2 (16, 17, 5), (18, 6, 7)
        becomes
    - VTX (1 vtx, index 5, <src offset of "real" 5s data>)
    - TRI1 (0, 1, 5)
    - VTX (1 vtx, index 5, <src offset of "fake" 5s data>)
    - VTX (1 vtx, index 6, <src offset of "real" 6s data>)
    - VTX (1 vtx, index 7, <src offset of "real" 7s data>)
    - TRI1 (2, 6, 7)
    - VTX (1 vtx, index 6, <src offset of "fake" 6s data>)
    - VTX (1 vtx, index 7, <src offset of "fake" 7s data>)
- REMAINING PROBLEMS:    ! possible performance issues because of the repeated VTX cmds used to load a single vtx
                         - maybe not as serious on emulators, but might make for serious performance hit on real hardware
                         ! constellations like TRI1 (21, 22, 5) are IMPOSSIBLE because that becomes TRI1 (5, 6, 5) after above procedure where 5 and 5 really are two different vtxs!
                         - fixing the constellation problem would require rearranging the vtx data itself, duplicating vtxs where needed, and heavy TRIx parameter modification
                         - difficult to implement automatically?


Incomplete, untested theory I cooked up at 1am or something like that (1:45am here now). Just wanted to throw this out. Into a semi-closed forum, but what the hell. Spin? Wareya? Someone else?

God I'm tired.
Logged
cu xdaniel

Nanami - Desktop:

Kazari - Notebook:

spinout

  • Administrator
  • Sr. Member
  • *****
  • Posts: 309
    • View Profile
    • Email
Re: F3DEX to Fast3D conversion
« Reply #1 on: January 19, 2010, 06:42:42 AM »

I've told a few people the password, Wareya being one of them. I skimmed your post, and realized I don't know much about vertex commands for any other ucodes than F3DEX2. Besides geometry drawing though, textures are identical with all the formats, right?
Logged
biggrin.gif

xdaniel

  • Global Moderator
  • Sr. Member
  • *****
  • Posts: 295
    • ICQ Messenger - 136250978
    • View Profile
Re: F3DEX to Fast3D conversion
« Reply #2 on: January 19, 2010, 01:13:39 PM »

Actually, many commands are shared between all Ucodes, the ones prefixed G_ in ex. glN64 and OZMAV, including most texturing-related ones. Some key ones, however, differ in command byte, syntax or plain technical differences (ex. VTX and the vertex buffer size as mentioned) from their counterparts in other Ucodes: VTX (buffer size 16 VS 32 verts), TRI1 and TRI2 (syntax and/or command byte), TEXTURE (command byte), GEOMETRYMODE (was two commands in Fast3D, SET and CLEAR) and if I recall SETOTHERMODE_L and _R (syntax) are some offenders that need to be changed when converting like that. Can't remember everything on top of my head, but besides the vertex buffer size difference, all other commands could most likely be converted automatically.
Logged
cu xdaniel

Nanami - Desktop:

Kazari - Notebook:

Zeth

  • Full Member
  • ***
  • Posts: 161
    • View Profile
Re: F3DEX to Fast3D conversion
« Reply #3 on: January 21, 2010, 03:15:05 AM »

It definitely would be amazing to have a nice converter like that, or even a BK>OoT or vice versa. :D
*pulls medli into the discussion*
Logged

medli

  • Newbie
  • *
  • Posts: 1
    • View Profile
    • Email
Re: F3DEX to Fast3D conversion
« Reply #4 on: January 21, 2010, 03:29:20 AM »

I agree fully, seeing the Spiral Mountain model from Banjo Kazooie ported into another game was amazing :D

What do we know about model data that applies to every N64 game? As far as I understand, model data gets parsed by the games ucode (which is some assembly code that's compiled into the game?) and put into a format usable by the RSP/RDP. Since there are already graphics plugins that support dumping model data from any N64 game while it's running, could partially emulating a ROM lead to being able to  rip it's model data into a format we can already put in other games? (Like obj, which now has converters for OoT and Mario 64)
Logged

SirTopHat

  • Jr. Member
  • **
  • Posts: 96
    • View Profile
Re: F3DEX to Fast3D conversion
« Reply #5 on: January 21, 2010, 07:49:04 PM »

I'd like to see SM64 in OoT.
Logged
fgsfds

Zeth

  • Full Member
  • ***
  • Posts: 161
    • View Profile
Re: F3DEX to Fast3D conversion
« Reply #6 on: January 22, 2010, 05:43:55 AM »

Work in Progress using other methods >.>;






I need to fix rotation, size and remove the garbage graphics that didn't port correctly.
« Last Edit: January 22, 2010, 05:45:28 AM by Zeth »
Logged

xdaniel

  • Global Moderator
  • Sr. Member
  • *****
  • Posts: 295
    • ICQ Messenger - 136250978
    • View Profile
Re: F3DEX to Fast3D conversion
« Reply #7 on: January 29, 2010, 09:41:39 PM »





Semi-automatic Fast3D to F3DEX2 conversion. Textures are junk because Mario 64 uses RAM segments extensively while OoT doesn't. Also, collision is non existant (or rather, sasatest's) since this is just some Display Lists. Also, whichever few files come after sasatest's map file in the ROM have been overwritten - I was too lazy to mess with map headers and shit, and sasatest's was the easiest to work with for this.

On the plus side, texture coordinates should be correct since the vertex data is identical to SM64's.

EDIT:


Looks are pretty good, aren't they? Execution is kinda ugly and limited, tho...

The not really useful code so far: http://pastebin.com/m67b656fb

EDIT2: http://www.youtube.com/watch?v=UCcwhScJhjo
« Last Edit: January 29, 2010, 11:27:57 PM by xdaniel »
Logged
cu xdaniel

Nanami - Desktop:

Kazari - Notebook:

Arcaith

  • Administrator
  • Full Member
  • *****
  • Posts: 152
  • Keeping it real. Or something.
    • MSN Messenger - henna.gaikokujin@gmail.com
    • View Profile
    • Email
Re: F3DEX to Fast3D conversion
« Reply #8 on: January 30, 2010, 03:32:34 AM »

Looks really nice man :D
Logged
pantsu~

SirTopHat

  • Jr. Member
  • **
  • Posts: 96
    • View Profile
Re: F3DEX to Fast3D conversion
« Reply #9 on: January 30, 2010, 06:55:12 PM »

Those are cool
The first one, I was thinking "Super Mario's Death Castle". Why didn't the transparency on the windows go through correctly?
Logged
fgsfds

Arcaith

  • Administrator
  • Full Member
  • *****
  • Posts: 152
  • Keeping it real. Or something.
    • MSN Messenger - henna.gaikokujin@gmail.com
    • View Profile
    • Email
Re: F3DEX to Fast3D conversion
« Reply #10 on: January 31, 2010, 01:40:15 AM »

Looks like he's just not parsing the transparency data yet.
Logged
pantsu~

SirTopHat

  • Jr. Member
  • **
  • Posts: 96
    • View Profile
Re: F3DEX to Fast3D conversion
« Reply #11 on: January 31, 2010, 02:09:01 AM »

Looks like he did on Peach's picture though.
Logged
fgsfds

Arcaith

  • Administrator
  • Full Member
  • *****
  • Posts: 152
  • Keeping it real. Or something.
    • MSN Messenger - henna.gaikokujin@gmail.com
    • View Profile
    • Email
Re: F3DEX to Fast3D conversion
« Reply #12 on: January 31, 2010, 06:45:52 AM »

No, I think that might be a gap in the geometry.
Logged
pantsu~

xdaniel

  • Global Moderator
  • Sr. Member
  • *****
  • Posts: 295
    • ICQ Messenger - 136250978
    • View Profile
Re: F3DEX to Fast3D conversion
« Reply #13 on: January 31, 2010, 08:29:16 PM »

Missing texture transparency: It's not being turned on, I guess... Mario 64 probably has it on by default, I don't know, but it's certainly fixable. And nope, it's not working on Peach's portrait either.

Also, I've been slaving away on the converter for the last few hours and made it much easier to use. Taking parts from both OZMAV and MariOZMAV, it now interprets enough of Mario's level layout and geometry scripts to populate RAM segments, get texture and Display List offsets, etc. and in the end spits out a neat little .zmap file that's basically ready to insert into OoT. All it needs now is an expanded Mario 64 ROM, the name of the zmap/zscene pair you want to create and the ID of the level you want to convert.

Problems or uncertainties so far:
- it doesn't actually create a proper scene file and thus still doesn't create collision data
- the only tested Mario 64 level is the Castle Grounds, I don't know how it fares with more complex levels (testing this next)
- the code is barely documented and especially the script interpreter is as messy as ever
- ...probably more

EDIT: Wet-Dry World:



Good: no graphical glitches besides the missing transparency. Bad: both parts of the level are being converted into one, while in Mario 64 the "over-water" part and the underwater town are two seperate level areas. Area can now be selected via command line.

And thanks to the rewritten converter, all I had to change was the level ID in the command line parameters :D

btw, the command line: "F3DtoF3DEX2.exe sm64.z64 test 0x0C" - compared to "F3DtoF3DEX2.exe raw.bin conv.bin tex.bin 0xc4c0 0x5f60 0x6ed8 0x89f8 0x96f8 0xa728 0xb240 0xb820 0xbab8 0xc3a0 0xc4c0 0xc070 0xc2a0" previously :P
« Last Edit: January 31, 2010, 09:45:26 PM by xdaniel »
Logged
cu xdaniel

Nanami - Desktop:

Kazari - Notebook:

SirTopHat

  • Jr. Member
  • **
  • Posts: 96
    • View Profile
Re: F3DEX to Fast3D conversion
« Reply #14 on: February 01, 2010, 12:06:07 AM »

Great work here
Logged
fgsfds
Pages: [1] 2 3 4