|
|
GoldenEye 007 Nintendo 64 Community, GoldenEye X, Nintendo 64 Games Discussion GoldenEye Cheats, GoldenEye X Codes, Tips, Help, Nintendo 64 Gaming Community
|
|
|
|
|
|
|
|
|
|
|
sobinist Agent
Joined: 03 Jan 2016 Posts: 2
|
Posted: Sun Jan 03, 2016 11:08 am Post subject: Rayman 2 N64 Geometry Extraction |
|
|
Hey all, I've been trying to extract the geometry from Rayman 2: The Great Escape on the N64.
I did find out a few things already (for instance I know where vertices are stored and roughly how polygons are stored) but to continue I need to know how exactly the game associates the polygons with the vertices (polygons have a local vertex number like 0, 1, 2 while the vertices themselves don't have such an identification, they are just stored in one big chunk of data).
I documented things I have found out already over here.
Could anyone help me out with this? I was referred to this site by Acceptable67 who said people here could probably help me with this
Thanks in advance for your response! |
|
|
|
|
|
|
|
|
|
|
SubDrag Administrator
Joined: 16 Aug 2006 Posts: 6125
|
Posted: Sun Jan 03, 2016 12:32 pm Post subject: |
|
|
Everything you've got looks right. From what I can tell, Rayman 2 is F3DEX GBI1.
That's very common. Command 0x04 is a way to map to the vertices from the displaylist. It basically chooses vertex offset, then loads textures and mipmaps etc (annoying complicated commands), then it will draw (BF/B1).
From one of your samples, seems like just starts at vertex offset 0. B2 commands are NOOPs, so maybe Rayman overloaded that in software to be texture expansion?
(from Mupen src,in command order)
UcodeMap ucodeMap1 =
{
RSP_GBI1_SpNoop, RSP_GBI0_Mtx, RSP_GBI1_Reserved, RSP_GBI1_MoveMem,
RSP_GBI1_Vtx, RSP_GBI1_Reserved, RSP_GBI0_DL, RSP_GBI1_Reserved,
RSP_GBI1_Reserved, RSP_GBI1_Sprite2DBase, RSP_RDP_Nothing, RSP_RDP_Nothing,
RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing,
//10
RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing,
RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing,
RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing,
RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing,
//20
RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing,
RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing,
RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing,
RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing,
//30
RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing,
RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing,
RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing,
RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing,
//40
RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing,
RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing,
RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing,
RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing,
//50
RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing,
RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing,
RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing,
RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing,
//60
RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing,
RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing,
RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing,
RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing,
//70
RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing,
RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing,
RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing,
RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing,
//80
RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing,
RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing,
RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing,
RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing,
//90
RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing,
RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing,
RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing,
RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing,
//a0
RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing,
RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing,
RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing,
RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_GBI1_LoadUCode,
//b0
RSP_GBI1_BranchZ, RSP_GBI1_Tri2, RSP_GBI1_ModifyVtx, RSP_GBI1_RDPHalf_2,
RSP_GBI1_RDPHalf_1, RSP_GBI1_Line3D, RSP_GBI1_ClearGeometryMode, RSP_GBI1_SetGeometryMode,
RSP_GBI1_EndDL, RSP_GBI1_SetOtherModeL, RSP_GBI1_SetOtherModeH, RSP_GBI1_Texture,
RSP_GBI1_MoveWord, RSP_GBI1_PopMtx, RSP_GBI1_CullDL, RSP_GBI1_Tri1,
//c0
RSP_GBI1_Noop, RSP_S2DEX_SPObjLoadTxtr_Ucode1, RSP_RDP_Nothing, RSP_RDP_Nothing,
RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing,
RDP_TriFill, RDP_TriFillZ, RDP_TriTxtr, RDP_TriTxtrZ,
RDP_TriShade, RDP_TriShadeZ, RDP_TriShadeTxtr, RDP_TriShadeTxtrZ,
//d0
RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing,
RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing,
RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing,
RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing,
//e0
RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing, RSP_RDP_Nothing,
DLParser_TexRect, DLParser_TexRectFlip, DLParser_RDPLoadSync, DLParser_RDPPipeSync,
DLParser_RDPTileSync, DLParser_RDPFullSync, DLParser_SetKeyGB, DLParser_SetKeyR,
DLParser_SetConvert, DLParser_SetScissor, DLParser_SetPrimDepth, DLParser_RDPSetOtherMode,
//f0
DLParser_LoadTLut, RSP_RDP_Nothing, DLParser_SetTileSize, DLParser_LoadBlock,
DLParser_LoadTile, DLParser_SetTile, DLParser_FillRect, DLParser_SetFillColor,
DLParser_SetFogColor, DLParser_SetBlendColor, DLParser_SetPrimColor, DLParser_SetEnvColor,
DLParser_SetCombine, DLParser_SetTImg, DLParser_SetZImg, DLParser_SetCImg
}; |
|
|
|
|
|
|
|
|
|
|
sobinist Agent
Joined: 03 Jan 2016 Posts: 2
|
Posted: Sun Jan 03, 2016 3:19 pm Post subject: |
|
|
Wow, that's very helpful information, thanks!
I do still have a question about the offsets though; you mentioned the offset for the examples appears to be 0, but that can't be the case since the vertices for the stone and the lantern are located at offsets A442AE and A4413E respectively. Is there any other place these offsets could be stored so I can retrieve them?
EDIT: also from what I can see from your RSP command list, B2 is actually "RSP_GBI1_ModifyVtx". I could be wrong though |
|
|
|
|
|
|
|
|
|
|
SubDrag Administrator
Joined: 16 Aug 2006 Posts: 6125
|
Posted: Sun Jan 03, 2016 3:53 pm Post subject: |
|
|
Oops you're right, it is modify vertex. I think the 04 commands can be relative, not just absolute, like the game itself can transform to make the real spot. I'm not that familiar with modify vertex, perhaps its related...but then I'm not sure where textures are. |
|
|
|
|
|
|
|
|
|
|
Trevor 007
Joined: 15 Jan 2010 Posts: 926 Location: UK, Friockheim OS:Win11-Dev PerfectGold:Latest |
Posted: Mon Jan 04, 2016 2:14 am Post subject: |
|
|
If its using modify vertex then expect a lot of shared verticies.
It means that for each frame in the game, each vertex does a number of transformations (size, position, rotation) and the TransVerts are spat out.
Since transformations take time, instead of making a cube out of 6x3 verticies, you could make it out of 8 Verticies and use modifyVTX to add different colour or UV to each vertex AFTER the transform.
So, instead of transforming 18 verticies every frame, you only transofrm 8 and just keep adding the missing info at triangle draw.
Draw Triangle 1 (0,1,2) //side1
modifyvtx0 (change rgb and UV)
modifyvtx1 (change rgb and UV)
draw another triangle (0,1,3) //side2 (3 is a seperate vertex otherwise we would be overdrawing a previous triangle)
etc...
Again though, this could be bad with more GBI commands.
I dont think there is a definitive faster/slower method.
GBi at vertex expence OR Vertex and GBI expence.
Trev _________________
|
|
|
|
|
|
|
|
|
|
|
Kerr Avon 007
Joined: 26 Oct 2006 Posts: 913
|
Posted: Mon Jan 04, 2016 3:24 pm Post subject: |
|
|
Out of interest, what languages were N64 games programmed in? C++, assembler, or what? |
|
|
|
|
|
|
|
|
|
|
pavarini 00 Agent
Joined: 07 May 2015 Posts: 479
|
|
|
|
|
|
|
|
|
|
|
Trevor 007
Joined: 15 Jan 2010 Posts: 926 Location: UK, Friockheim OS:Win11-Dev PerfectGold:Latest |
Posted: Thu Jan 07, 2016 12:56 pm Post subject: |
|
|
Now, Im not sure, but there are lots of references to C++ in the SDK header files, so it may have been cross compatable.
But all the documentation is in C.
The compiler, exeGCC, was made as a windows executable by Kyoto Micro Computer.
Trev _________________
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|
|
|