Register - Login
Views: 95818580
Main - Memberlist - Active users - Calendar - Wiki - IRC Chat - Online users
Ranks - Rules/FAQ - Stats - Latest Posts - Color Chart - Smilies
11-20-18 11:30:08 AM

Jul - SM64 Hacking (Archive) - SM64 RSP Commands New poll - New thread - New reply
Next newer thread | Next older thread
rstewart215804
User
Crazed Mario 64 Hacker!!!
Level: 11


Posts: 6/18
EXP: 4881
For next: 1104

Since: 09-12-07


Since last post: 9.0 years
Last activity: 8.0 years

Posted on 10-22-07 04:11:32 PM Link | Quote
Over the past few years VL-Tone and many others have hacked and worked with SM64, however there is still a few left barriers to overcome. The first one is the N64 RSP microcode. (It is draws the polygons in the game.) VL-Tone has found out how some of the commands work but there is still more. If we knew how all the commands work then we could create levels from scratch. I suggest all of us Rom hackers come together and help. I will search my notes tonight and give post all the information I have.

On a side note in a few weeks a will release a collision data editor. Currently I am rebuilding my editor from the ground up to remove some of the bugs that I had with my first test version. I use the same software as VL-Tone which means that my editor is cross platform.
VL-Tone
Member
Super Mario 64 forum moderator
Level: 51


Posts: 118/621
EXP: 994957
For next: 18981

Since: 07-27-07

From: Montreal, Canada

Since last post: 1.0 years
Last activity: 37 days

Posted on 10-24-07 04:07:24 AM Link | Quote
I'm all for finding the purpose of remaining GBI/RSP commands. But, I'll add my unfortunately pessimistic view on what could follow...

Even if we knew all RSP commands, it wouldn't mean it would be easy to import external models. These commands put very specific restrictions on the way models are constructed, and 3d modeling programs don't know anything about these limitations.

Super Mario 64 models were created with Nichimen N-World, a program that was partly developed in collaboration with Nintendo, so it could take into account all the specific requirements of the N64 RSP command set. A special custom-made plug-in for this program exported models to GBI/RSP commands. N-World is not simply a modeler, it has some feature that made it easy to create worlds and objects suited for the n64 platform. Some RSP commands have no direct equivalents in modern 3d modelers.

The Goldeneye editor can import external 3d models, but that's because Rare used a completely different engine and modeler, with a more modern data-driven approach for model data instead of the command-driven approach used by early Nintendo games like SM64. Rare used a different approach precisely to avoid the problems I'm describing in the SM64 approach. Even then, the GE editor has its share of problems when importing models.

While we could define a set of guidelines that users would have to follow when creating/exporting their 3d models from their 3d modeler, just defining these guidelines would be a tough job in itself. And then, I can already imagine all sorts of emerging issues, which would be hard to sort out since not all users would have followed the guidelines in the first place.

I know I sound overly pessimistic when I talk about this, but to me knowing all RSP commands is a very small part of the solution to a bigger problem.

I guess it's a first step, and I don't want to discourage any efforts to crack the remaining RSP commands. I just don't want people to expect me to easily implement a model importer in TT64 just because we know the purpose of all commands. If you or anyone else want to create an importer then, have fun, but it won't be a piece of cake.

Anyhow, I'd be happy if you could prove me wrong

Don't hesitate to still post your notes, and I'll add a few things I may have not included in my docs.

Mega Mario XD
80
Level: 21


Posts: 34/81
EXP: 46355
For next: 3588

Since: 10-26-07

From: Australia

Since last post: 10.0 years
Last activity: 10.0 years

Posted on 12-03-07 03:06:26 AM Link | Quote
Originally posted by VL-Tone
I'm all for finding the purpose of remaining GBI/RSP commands. But, I'll add my unfortunately pessimistic view on what could follow...

Even if we knew all RSP commands, it wouldn't mean it would be easy to import external models. These commands put very specific restrictions on the way models are constructed, and 3d modeling programs don't know anything about these limitations.




Some guy said he imported a Mario Party 3 Daisy Model into SM64 and fixed all the animations. I'll see if I can get him to reveal his secrets...
paulguy

Green Birdo
Level: 90


Posts: 13/2294
EXP: 7022279
For next: 166330

Since: 09-14-07

From: Buffalo, NY

Since last post: 6.0 years
Last activity: 6.0 years

Posted on 12-04-07 12:35:02 PM Link | Quote
Since when is TT64 cross platform compatible?
VL-Tone
Member
Super Mario 64 forum moderator
Level: 51


Posts: 120/621
EXP: 994957
For next: 18981

Since: 07-27-07

From: Montreal, Canada

Since last post: 1.0 years
Last activity: 37 days

Posted on 12-06-07 01:35:09 PM Link | Quote
Originally posted by paulguy
Since when is TT64 cross platform compatible?


Since the beginning, it works on both Windows and Mac OS X. Unfortunately it's not running natively in Linux (some people reported success under Wine, though the ROM extender doesn't work). It's not that I don't care about Linux, but I started using Director as a development platform a long time before Linux was on the map and even before it was released, and Director is what I know best, by far.

As for the guy that supposedly imported the Mario Party 3 Daisy model into SM64 and fixed the animations, I say it's complete bullshit. Tell him to come post here and show some proofs (and that means a video not some photoshoped screenshot).
Mega Mario XD
80
Level: 21


Posts: 43/81
EXP: 46355
For next: 3588

Since: 10-26-07

From: Australia

Since last post: 10.0 years
Last activity: 10.0 years

Posted on 12-07-07 01:09:50 AM Link | Quote
Originally posted by VL-Tone

As for the guy that supposedly imported the Mario Party 3 Daisy model into SM64 and fixed the animations, I say it's complete bullshit. Tell him to come post here and show some proofs (and that means a video not some photoshoped screenshot).


I'll get a video of him as soon as he's available to show off some screen shots.

He knows what he's doing. I contacted him for some help on the Peachy64 Project.
Rena

Star Mario
Fennel
Level: 129


Posts: 1809/5258
EXP: 24529102
For next: 520552

Since: 07-22-07

Pronouns: he/him/whatever
From: RSP Segment 6

Since last post: 27 days
Last activity: 17 days

Posted on 12-13-07 11:44:24 PM Link | Quote
I'm wondering how similar SM64's and MK64's microcodes are. Just for a quick comparison, here's some RSP command dumps from Mario Kart:

000000 FC 12 18 24 FF 33 FF FF Set Combine - muxs0=121824 muxs1=FF33FFFF
000008 B9 00 03 1D 00 55 20 78 Set Other Mode L - 00 03 1D 00 55 20 78
000010 06 00 00 00 07 00 14 A0 Display List - addr=07:0014A0
000018 06 00 00 00 07 00 09 C0 Display List - addr=07:0009C0
000020 06 00 00 00 07 00 06 88 Display List - addr=07:000688
000028 06 00 00 00 07 00 03 F0 Display List - addr=07:0003F0
000030 B8 00 00 00 00 00 00 00 End Display List - 00 00 00 00 00 00 00
000038 FF DA 00 00 02 E8 00 00 Set CIMG - DA 00 00 02 E8 00 00


000000 FC 12 7E 24 FF FF F3 F9 Set Combine - muxs0=127E24 muxs1=FFFFF3F9
000008 B9 00 03 1D 00 55 30 78 Set Other Mode L - 00 03 1D 00 55 30 78
000010 B6 00 00 00 00 00 20 00 Clear Geometry Mode - 00 00 00 00 00 20 00
000018 06 00 00 00 07 00 02 38 Display List - addr=07:000238
000020 B7 00 00 00 00 00 20 00 Set Geometry Mode - 00 00 00 00 00 20 00
000028 FC 12 18 24 FF 33 FF FF Set Combine - muxs0=121824 muxs1=FF33FFFF
000030 B9 00 03 1D 00 55 20 78 Set Other Mode L - 00 03 1D 00 55 20 78
000038 06 00 00 00 07 00 0F E8 Display List - addr=07:000FE8
000040 06 00 00 00 07 00 0C 60 Display List - addr=07:000C60
000048 06 00 00 00 07 00 0B 70 Display List - addr=07:000B70
000050 06 00 00 00 07 00 06 B8 Display List - addr=07:0006B8
000058 06 00 00 00 07 00 05 70 Display List - addr=07:000570
000060 B6 00 00 00 00 00 20 00 Clear Geometry Mode - 00 00 00 00 00 20 00
000068 06 00 00 00 07 00 10 C8 Display List - addr=07:0010C8
000070 B7 00 00 00 00 00 20 00 Set Geometry Mode - 00 00 00 00 00 20 00
000078 B8 00 00 00 00 00 00 00 End Display List - 00 00 00 00 00 00 00
000080 FF EE 01 E0 01 6D 00 00 Set CIMG - EE 01 E0 01 6D 00 00
000088 FE F0 01 E0 01 38 00 00 Set ZIMG - F0 01 E0 01 38 00 00
000090 FE C8 01 E0 01 67 00 00 Set ZIMG - C8 01 E0 01 67 00 00
000098 FE DB 01 E0 01 51 00 00 Set ZIMG - DB 01 E0 01 51 00 00


000000 BB 00 00 01 FF FF FF FF Texture-related - 00 00 01 FF FF FF FF
000008 B6 00 00 00 00 02 00 00 Clear Geometry Mode - 00 00 00 00 02 00 00
000010 C0 00 00 00 00 00 00 00 RDP NOP - 00 00 00 00 00 00 00
000018 BA 00 0C 02 00 00 20 00 Set Other Mode H - 00 0C 02 00 00 20 00
000020 BA 00 13 01 00 08 00 00 Set Other Mode H - 00 13 01 00 08 00 00
000028 E8 00 00 00 00 00 00 00 RDP Tile Sync - 00 00 00 00 00 00 00
000030 F5 70 10 00 00 09 40 50 Set Tile - fmt=3 size=2 ?=0 line=8 TMem=0 tile=0 palette=0 ?=1, 0 MaskT=1 ShiftT=0 ?=0, 0 masks=5 shifts=0
000038 F2 00 00 00 00 07 C0 7C Set Tile Size - texcoord=0, 0; tile=0, ?=07C07C
000040 FD 70 00 00 05 00 00 00 Set Texture Location - fmt=3 txsize=2 width=1 addr=05000000
000048 E8 00 00 00 00 00 00 00 RDP Tile Sync - 00 00 00 00 00 00 00
000050 F5 70 00 00 07 00 00 00 Set Tile - fmt=3 size=2 ?=0 line=0 TMem=0 tile=7 palette=0 ?=0, 0 MaskT=0 ShiftT=0 ?=0, 0 masks=0 shifts=0
000058 E6 00 00 00 00 00 00 00 RDP Load Sync - 00 00 00 00 00 00 00
000060 F3 00 00 00 07 3F F1 00 Load Texture - texcoord=0, 0; tile=7, ?=3FF100
000068 FC 12 7E 24 FF FF F3 F9 Set Combine - muxs0=127E24 muxs1=FFFFF3F9
000070 B9 00 03 1D 00 50 49 D8 Set Other Mode L - 00 03 1D 00 50 49 D8
000078 B8 00 00 00 00 00 00 00 End Display List - 00 00 00 00 00 00 00
000080 B9 00 03 1D 00 40 45 D8 Set Other Mode L - 00 03 1D 00 40 45 D8
000088 FC 12 18 24 FF 33 FF FF Set Combine - muxs0=121824 muxs1=FF33FFFF
000090 E8 00 00 00 00 00 00 00 RDP Tile Sync - 00 00 00 00 00 00 00
000098 F5 10 20 00 00 01 40 60 Set Tile - fmt=0 size=2 ?=0 line=16 TMem=0 tile=0 palette=0 ?=0, 0 MaskT=1 ShiftT=0 ?=0, 0 masks=6 shifts=0
0000A0 F2 00 00 00 00 0F C0 7C Set Tile Size - texcoord=0, 0; tile=0, ?=0FC07C
0000A8 FD 10 00 00 05 00 20 00 Set Texture Location - fmt=0 txsize=2 width=1 addr=05002000
0000B0 E8 00 00 00 00 00 00 00 RDP Tile Sync - 00 00 00 00 00 00 00
0000B8 F5 10 00 00 07 00 00 00 Set Tile - fmt=0 size=2 ?=0 line=0 TMem=0 tile=7 palette=0 ?=0, 0 MaskT=0 ShiftT=0 ?=0, 0 masks=0 shifts=0
0000C0 E6 00 00 00 00 00 00 00 RDP Load Sync - 00 00 00 00 00 00 00
0000C8 F3 00 00 00 07 7F F0 80 Load Texture - texcoord=0, 0; tile=7, ?=7FF080
0000D0 B8 00 00 00 00 00 00 00 End Display List - 00 00 00 00 00 00 00


Any similarities? It'd really be nice if they used the same microcode, then we'd have less work to do.
VL-Tone
Member
Super Mario 64 forum moderator
Level: 51


Posts: 125/621
EXP: 994957
For next: 18981

Since: 07-27-07

From: Montreal, Canada

Since last post: 1.0 years
Last activity: 37 days

Posted on 12-14-07 03:55:58 PM Link | Quote
Here are the microcode commands used for polygon models in SM64.


----------------------------
| Polygon drawing Commands |
----------------------------

[F3] [00 0,0 00] 07 [7F F][1 00]

[1] : F3 = command to load the texture into the texture memory along with more settings
[2,3,4] : the s, t coordinates of the upper left corner of the texture tile in fixed point
format (not used?)
[5] : the tile number on the lower 3 bits
[6,7,8]: width and height of texture represented as a slant. hhhwww
width=256/www*32
height=hhh/32/width

------------------------------------

[FD] [10] 00 00 [09] [00 48 00]

[1]: FD = load texture
[3] : format/pixel size fffpp000
f = format
RGBA = 000 (there are other options)
p = storage size of 1 texel
16 bits = 10 (other options too)
0 = unused

[5]: RAM segment number
[6,7,8]: Offset in segment

------------------------------------

[03] [88] [00 10] [08] [00 C0 90]

[1]: 03= Load color for next triangles.
[2]: When is 0x86, loads the bright color, when 0x88(?) loads darkened color.
[3,4]: ??
[5]: RAM segment number
[6,7,8]: Offset in segment
(colors referred are in 32-bit RGBA format 8888)

------------------------------------

[04] [B0] [00 C0] [07 00 BD 50]

[1]: 04= Loads a chunk of vertices into RSP (The RSP cannot contain too much vertices)
[2] : number of vertices minus one in the high nibble and where in the vertex cache to load in
the low nibble
(eg 0xb+1= 0xc=12 vertices loaded into index 0)
[3,4] : number of bytes of vertex data to load( 16(dec) for each vertex) (redundant?)
[5]: RAM segment number
[6,7,8]: Offset in segment and base address for next triangles.

------------------------------------

[F5] [00 00 00 00 00 00 00]

[1]: F5= Texture mode
[2,8]: Texture mode bits: lllkk.jj jjjjjjji iiiiiiii .....hhh ggggffee eeddddcc bbbbaaaaa
ff= Clamping S coord (cms)
cc= Clamping T coord (cmt)
bbbb= Mask offset S coord (masks)
eeee= Mask offset T coord (maskt)

------------------------------------

[B6] [00 00 00] [00 00] [00 00]

[1]: B6= Clears geometry mode
[5,6]: Culling and other settings, 16-bits= ??ab???? ???????? where a=culling back and b=culling front
[7,8]: Other geometry settings, 16-bits

------------------------------------

[B7] [00 00 00] [00 00] [00 00]

[1]: B7= Clears geometry mode
[5,6]: Culling and other settings, 16-bits= ??ab???? ???????? where a=culling back and b=culling front
[7,8]: Other geometry settings, 16-bits

------------------------------------

[BF] [00 00 00] [00] [28 32 3C]

[1] : BF= Triangle command
[2,3,4] : mean nothing and are likely ignored
[5] : vertex to get normal or color from for flat shading, if flat shading is used; seems to
always be 0.
[6,7,8] : vertex number times 10(dec)

------------------------------------

[06] 00 00 00 [04] [00 CA 00]

[1]: 06= Jumps to another point in the triangle data.
[2,3,4]:??
[5]: RAM segment number
[6,7,8]: Offset in segment

------------------------------------

[B8] [00 00 00 00 00 00 00]

[1]: B8: Command that jumps back to the next command after the last "06" jump (uses a stack)
[2-8]: always zero

------------------------------------

[E6] [00 00 00 00 00 00 00]

[1]: E6= This is just makes the RSP wait until it is not using any textures,
or something like that, in preparation for loading the texture image.
[2-8]: always zero

------------------------------------

Other additional polygon (RSP graphic lib) commands are used in SM64:
E6, BA, B9, F8, BC, FB, FF, BB, FC, E7, E8 and F2.



So they seem very similar, but some commands may not be used in MK64 and vice-versa.

Note that I lost some additional info I had from Cellar Dweller about commands B6, B7 and F5, which were in some private messages on the other boards (and that I stupidly didn't save on my computer).

Command 0x06, which I called the "jump command" is more than probably the same as what you rightly called "Display list", same goes for the 0xB8 command.

You seem to have amassed much more info about the RSP polygon drawing microcode than I did. I essentially stopped looking once I was able to display levels and polygon in a "good enough" manner in TT64. It would be useful for SM64 hacking if you could publish some of the info you have about RSP drawing microcode since they are after all so similar. Maybe it would be time to change the title of this forum to "N64 hacking", though there's a lot of SM64 stickies in here.

I don't think it would be incredibly hard to import/export models between SM64 and MK64, though using models as levels would require more work, because of the collision map and other level properties. In any case it would require more than copy/paste, and automating the process wouldn't be necessarily easy.

But may I reiterate that replacing Mario with an imported model is far from being a piece of cake, and I remain skeptical about that mysterious guy that still can't provide a proof of his supposed importation of Daisy in SM64 (Mario Party 3 is a much more recent game than MK64 and SM64, I'm not even sure it uses the same microcode). And like I said, Mario's body part hierarchy is particular, and you can't easily fit any character in it.
Rena

Star Mario
Fennel
Level: 129


Posts: 1815/5258
EXP: 24529102
For next: 520552

Since: 07-22-07

Pronouns: he/him/whatever
From: RSP Segment 6

Since last post: 27 days
Last activity: 17 days

Posted on 12-14-07 08:56:23 PM Link | Quote
I don't think microcodes are tweaked much at all for individual games, but Mario Kart may be using a later/customized version. I've seen it called F3DEX. (Unfortunately, Googling this is pretty useless because it's 1337 for Fedex. )

A display list is just what they call the subroutines, so 06 is a "call subroutine" command as you've described. It looks like they might be nearly identical. Nice.

I don't think much could be done in the way of exchanging models. The majority of the objects are really just 2D sprites. The only models I've dealt with are the tracks themselves, and rendering a track correctly relies heavily on correct interpretation of the RSP commands, since the tracks are basically just a whole lot of these commands and a coordinate table for them to refer to for placing polygons. The rendering engine is surprisingly simple, the tricky part is emulating all those commands.

Here is a table of how many times each command is used in each level. "Level Commands" is a sort of high-level display list system, each of those is turned into one or more RSP commands. You can see for example 03 and 04 aren't used at all.

I think it might help if we had the source of a high-level RSP emulation plugin, but I haven't had any luck with that. All the open-source plugins I've found are low-level. I imagine a high-level emulator would ignore the actual microcode, except to check which it is, and just interpret these commands directly, so the source would be a huge help in understanding what they do. (Heck, maybe we could just load the plugin directly and let it do all the work. )
Mega Mario XD
80
Level: 21


Posts: 52/81
EXP: 46355
For next: 3588

Since: 10-26-07

From: Australia

Since last post: 10.0 years
Last activity: 10.0 years

Posted on 12-14-07 11:24:40 PM (last edited by Matthew Coburn at 12-14-07 11:27 PM) Link | Quote
Well, this is interesting. There is free space in the EXTended ROM that we *could* import data to.

Imagine a level like Toad's Turnpike. Sure, the Cars and Truck whould be screwed, but if we had the basic layout (the track itself) we could have a "Shroom City" Level in SM64.

I may sound like I'm talking about something random, but could it be possible for something along those lines?

EDIT: Is the MK64 Kart and Driver two seperate models, or one object?
Rena

Star Mario
Fennel
Level: 129


Posts: 1817/5258
EXP: 24529102
For next: 520552

Since: 07-22-07

Pronouns: he/him/whatever
From: RSP Segment 6

Since last post: 27 days
Last activity: 17 days

Posted on 12-14-07 11:27:43 PM Link | Quote
Very unlikely. The level formats are extremely different.
Joe
Common spammer
🍬
Level: 105


Posts: 203/3306
EXP: 12213761
For next: 48499

Since: 08-02-07

From: Pororoca

Since last post: 64 days
Last activity: 1 hour

Posted on 12-15-07 01:30:16 AM Link | Quote
Originally posted by HyperHacker
(Unfortunately, Googling this is pretty useless because it's 1337 for Fedex. )
And yet, when I Google F3DEX, the majority of the pages are about the microcode. The first result alone tells me that games like Bomberman Hero, StarFox 64, Super Mario 64, and Super Smash Bros - among others - all run with high-level emulation of that RSP microcode.

I think it's about time for me to download Project64...
Rena

Star Mario
Fennel
Level: 129


Posts: 1911/5258
EXP: 24529102
For next: 520552

Since: 07-22-07

Pronouns: he/him/whatever
From: RSP Segment 6

Since last post: 27 days
Last activity: 17 days

Posted on 12-25-07 03:48:01 AM Link | Quote
I guess there's been more info put up since I last did it. (Or maybe I was looking for f3d3x? ) That's good to know, but is this emulator open-source?

Also looking at that page, unless it's a mistake, Mario Kart is listed as F3DEX, while Quest64 is F3D3X, which is interesting. Mario 64 is Fast3D, which I believe is the predecessor to F3DEX (Fast3D-EX). So it may not support some of the commands Mario Kart does, and there's a chance some were removed or changed.

If you search for "RSP" in RAM you can actually find convenient identifier strings. Mario Kart has it at 800F3FB0:

RSP Gfx ucode F3DEX 0.95 Yoshitaka Yasumoto Nintendo.

Mario 64 has a different string at 80339D30:

RSP SW Version: 2.0D, 04-01-96.SGI U64 GFX SW TEAM: S Anderson, S Carr, H Cheng, K Luster, R Moore, N Pooley, A Srinivasan

(also, this string breaks Notepad )

Out of curiosity I checked Quest64 too. It's at 80072680:

RSP Gfx ucode F3DEX 1.23 Yoshitaka Yasumoto Nintendo
So, just a mistake I guess.

BTW, search for "rspark" at the title screen in Mario 64. What is that?




Good news. I confirmed that Fast3D and F3DEX are very similar. Using the video plugin "glN64 V0.4.1", when I loaded a hacked Mario Kart 64 ROM it asked me which microcode was supposed to be used. I chose Fast3D just to see what would happen. The result?


3D models are obliterated (the Nintendo logo is a mess of triangles, but still spins ), but the game runs and all 2D stuff such as the menus and timer display fine.
VL-Tone
Member
Super Mario 64 forum moderator
Level: 51


Posts: 157/621
EXP: 994957
For next: 18981

Since: 07-27-07

From: Montreal, Canada

Since last post: 1.0 years
Last activity: 37 days

Posted on 12-27-07 01:44:37 AM Link | Quote
I guess that moving models from SM64 to SMK64 would be easier than in the opposite direction?
Rena

Star Mario
Fennel
Level: 129


Posts: 1936/5258
EXP: 24529102
For next: 520552

Since: 07-22-07

Pronouns: he/him/whatever
From: RSP Segment 6

Since last post: 27 days
Last activity: 17 days

Posted on 12-27-07 02:03:08 AM (last edited by HyperHacker at 12-27-07 02:04 AM) Link | Quote
I don't know enough about Mario 64 to be sure, but really, there are very few models in this game. The tracks, item boxes (I think), Nintendo logo, trophies, palm trees, and moving objects (boat, train, chomp etc) are all that come to mind. Everything else is textured quads. If you've ever noticed things like the snowmen have no backs (you can even get 4 players each looking at a different side and they all see a face!) that would be why.

Of course you could easily export the models to a bunch of bitmaps and import them as textures in place of the old ones.

I would assume though that F3DEX supports more commands than Fast3D, but I don't see much reason to port raw RSP commands between the two.
VL-Tone
Member
Super Mario 64 forum moderator
Level: 51


Posts: 167/621
EXP: 994957
For next: 18981

Since: 07-27-07

From: Montreal, Canada

Since last post: 1.0 years
Last activity: 37 days

Posted on 01-05-08 08:53:29 PM Link | Quote
Originally posted by HyperHacker
I don't know enough about Mario 64 to be sure, but really, there are very few models in this game. The tracks, item boxes (I think), Nintendo logo, trophies, palm trees, and moving objects (boat, train, chomp etc) are all that come to mind. Everything else is textured quads. If you've ever noticed things like the snowmen have no backs (you can even get 4 players each looking at a different side and they all see a face!) that would be why.

Of course you could easily export the models to a bunch of bitmaps and import them as textures in place of the old ones.

I would assume though that F3DEX supports more commands than Fast3D, but I don't see much reason to port raw RSP commands between the two.


Yeah, SMK64 sure has a lot of "billboards" (flat sprites always facing the camera). I don't think we should spend any time trying to move models between the two games, but since Fast3D and F3DEX are similar, knowledge can be shared, hoping that we can eventually import/export models.

Here's some stuff from some doc that shall remain nameless:

The Seven Basic Microcodes
There are seven basic versions of the graphics microcode:
gspFast3D
gspF3DNoN
gspLine3D
gspTurbo3D
gspSprite2D
gspS2DEX
gspZ-Sort
Each basic version has a different set of graphics rendering features and up to three subtypes.

The F3DEX Microcode Series
In addition to the seven basic microcodes, there are seven additional modified versions of gspFast3D, gspF3DNoN, and gspLine3D that have been specially modified to .fifo subtypes to improve performance. These modified versions are:
gspF3DEX
gspF3DEX.NoN
gspF3DLX
gspF3DLX.NoN
gspF3DLX.Rej
gspF3DLP.Rej
gspL3DEX
Together these seven modified microcode versions are known as the "F3DEX microcode series" or the "F3DEX package."

F3DEX - gspF3DEX.fifo.o or gspF3DEX.NoN.fifo.o
These are extended versions of the Fast3D microcode. The vertex cache size is increased to 32, and gSP2Triangles, a GBI command for displaying two triangles at once, is supported. Not supported is the gSP1Quadrangle command, a GBI command for displaying rectangles that was supported in F3DEX Version 1.21 and earlier versions. (However, this is emulated by gSP2Triangles.)


The vertex cache size in Fast3d is 16 vertices, which is kinda limiting (well 32 is limiting too). A triangle can only access vertices from a scope of 16 vertices. The 0x04 command is used to load vertices, and subsequent triangle commands (0xBF) can only access vertices in the cache, so in some complex models you might end up storing multiple instances of the same vertices. Compiling microcode from imported models would require some optimization algorithm that would group sequences of vertices to avoid repetition and minimize the use of the 0x04 command. It can get complicated when models using multiple textures are broken down in pieces by the texture commands.
Rena

Star Mario
Fennel
Level: 129


Posts: 2075/5258
EXP: 24529102
For next: 520552

Since: 07-22-07

Pronouns: he/him/whatever
From: RSP Segment 6

Since last post: 27 days
Last activity: 17 days

Posted on 01-06-08 03:39:00 AM (last edited by HyperHacker at 01-06-08 03:40 AM) Link | Quote
Ah, that explains this:33 xx yy, 34 xx yy, 35 xx yy, 36 xx yy,
37 xx yy, 38 xx yy, 39 xx yy, 3A xx yy,
3B xx yy, 3C xx yy, 3D xx yy, 3E xx yy,
3F xx yy, 40 xx yy, 41 xx yy, 42 xx yy,
43 xx yy, 44 xx yy, 45 xx yy, 46 xx yy,
47 xx yy, 48 xx yy, 49 xx yy, 4A xx yy,
4B xx yy, 4C xx yy, 4D xx yy, 4E xx yy,
4F xx yy, 50 xx yy, 51 xx yy, 52 xx yy: Set polygon data offset.
yyxx: Offset (start of polygon data plus this)
Note: This is polygon #, multiply by 14 (0xE) to get address.
These commands set the location within the polygon file to read polygon data from, and upload polygon data to the RSP. The command # itself specifies the number of polygons. Note that 33 and 34 are never actually used in the game.
RSP Commands:
0400bbbb 04aaaaaa Load Vertex (b=# of bytes of vertex data, a=address to load from)
Note: The value of b is (Command # * 0x410) - 1. (todo: that can't be right )

I think I goofed up tracing that a bit (0x410?), and "polygons" should probably be replaced with "vertices". Either way, now I know why it does what it does if you switch those commands around.

It'd be interesting to see if we could move that spinning Nintendo logo to SM64, but I haven't looked into where it is in the ROM yet. I wouldn't be surprised if it's just some hardcoded display lists. Damn near everything is hardcoded in this game. (Fortunately, the routines are also quite inefficient and so can easily be replaced with ones that read from a table, leaving plenty of extra space. )
messiaen
Catgirl
Level: 65


Posts: 66/1085
EXP: 2265397
For next: 70231

Since: 11-20-07


Since last post: 4.0 years
Last activity: 3.0 years

Posted on 05-02-08 07:51:50 AM (last edited by messiaen at 05-03-08 07:16 PM) Link | Quote
I found this very useful bit of information by Cellar Dweller about commands 0xB7 and 0xB6:

---

SetGeometryMode and ClearGeometryMode are 0xb7 and 0xb6 respectively. There are no parameters in the first 32 bits. The lower 32 bits contain the flags that are to be set or cleared.

0x00000001 - use Z buffering
0x00000004 - use shading
0x00000200 - enable smooth shading(otherwise use flat shading)
0x00001000 - cull front facing triangles
0x00002000 - cull back facing triangles
0x00010000 - enable fog
0x00020000 - enable lighting
0x00040000 - generate texture coords using the normal
0x00080000 - generate texture coords (not sure how this works)

---

Searching Google for info I found this Mupen RSP_GX plugin source. In the beggining of the code there is a list of RSP commands.

The 0x40000 flag seems interesting, maybe I can use this to generate better texture coordinates for custom geometry. I searched for the ROM and it is used a few times, so I may investigate further. The 0x800000 is never used, maybe it only works with newer games/RSP version?
VL-Tone
Member
Super Mario 64 forum moderator
Level: 51


Posts: 363/621
EXP: 994957
For next: 18981

Since: 07-27-07

From: Montreal, Canada

Since last post: 1.0 years
Last activity: 37 days

Posted on 12-07-08 12:20:52 AM (last edited by VL-Tone at 12-07-08 12:51 AM) Link | Quote
Now that I'm thinking of fixing bugs in the TT64 polygon decoder, there's a few things I would like to confirm:

First is something I should've known from the beginning, but I'm just not sure anymore.

The SetGeometryMode will set the specified bit(s) to 1 leaving the other bits in the geometry mode intact, right?

The ClearGeometryMode will set the specified bit(s) to 0 leaving the other bits in the geometry mode intact, right?

Also, which bit is responsible for turning on polygon coloring? I mean, which bit will make the engine interpret the 3 last bytes or so of each vertex item as a color instead of a normal?

Is it 0x00000004 - use shading?

Edit:

I'm pretty sure it's this one instead.
0x00000200 - enable smooth shading(otherwise use flat shading)

It's the one I was using in TT64. I get generally good results, I get the shadow under the bridge in Castle Grounds (or in BBB) but I can't get the shadows on the top of the castle.
Next newer thread | Next older thread
Jul - SM64 Hacking (Archive) - SM64 RSP Commands New poll - New thread - New reply




Rusted Logic

Acmlmboard - commit 220d144 [2018-11-04]
©2000-2018 Acmlm, Xkeeper, Inuyasha, et al.

31 database queries, 10 query cache hits.
Query execution time: 0.179346 seconds
Script execution time: 0.045362 seconds
Total render time: 0.224708 seconds