spinout

Use Saria's hierarchy + animations + the logic from Saria's actor that sets it all up. Edit: with that matrix set to 0s, saria looks like this:

If you weren't planning on having it static, what were you planning? Static means - in this case - in the object file. That matrix is usually dynamic - generated each frame. You can't "port" data that is computed each frame.

You're not going to like this answer. I went on a wild goose chase in RAM, and here's what I got for the display list that renders Saria: The "format" of the 0xDB06 commands is: 0xDB0600xx zzzzzzzz x is segment * 4 z is the RAM address of that segment I reference them as 0xDB06 because 0xDB is used for many purposes, but it is only used for setting segments when it is 0xDB06. And a note on this perculiar matrix format: aaaabbbb ccccdddd eeeeffff gggghhhh iiiijjjj kkkkllll mmmmnnnn oooopppp AAAABBBB CCCCDDDD EEEEFFFF GGGGHHHH IIIIJJJJ KKKKLLLL MMMMNNNN OOOOPPPP lowercase are the portion of the number before the decimal point, uppercase/65536 is the portion of the number after the decimal point both are signed. Rows/columns: a = [1,1] b = [1,2] c = [1,3] d = [1,4] e = [2,1] .. h = [2,4] i = [3,1] .. l = [3,4] m = [4,1] .. p = [4,4] ex: [row 1, column 1] = a + (signed short)A/0x10000 The matrix components are as follows: Now, the bad news: This matrix is generated and modified each frame. You can't have it be static in an object file.

The pointer (don't reference it as bbxxxxxx! just xxxxxxxx! this nasty habit will come to bite you in the ass some day) is a pointer to a matrix. Matrices are very powerful - they can perform translation, rotation, and scaling all in a 4x4 data set, as described in the document I linked to. Internally, OoT uses matrices all over the main display list to correctly scale the map, and position and animate objects. In some cases, however, the actor will set up a matrix in a special segment - above segment 8 - and it is to be used to translate vertices, a well known example being the "cloth" that connects link's limbs. tbh I don't completely understand it myself.

Let's give gbi.h a look... ... #define G_MTX 0xda ... /* * G_MTX: parameter flags */ #ifdef F3DEX_GBI_2 # define G_MTX_MODELVIEW 0x00 /* matrix types */ # define G_MTX_PROJECTION 0x04 # define G_MTX_MUL 0x00 /* concat or load */ # define G_MTX_LOAD 0x02 # define G_MTX_NOPUSH 0x00 /* push or not */ # define G_MTX_PUSH 0x01 #else /* F3DEX_GBI_2 */ ... #define gDma2p(pkt, c, adrs, len, idx, ofs) \ { \ Gfx *_g = (Gfx *)(pkt); \ _g->words.w0 = (_SHIFTL((c),24,8)|_SHIFTL(((len)-1)/8,19,5)| \ _SHIFTL((ofs)/8,8,8)|_SHIFTL((idx),0,8)); \ _g->words.w1 = (unsigned int)(adrs); \ } ... #ifdef F3DEX_GBI_2 # define gSPMatrix(pkt, m, p) \ gDma2p((pkt),G_MTX,(m),sizeof(Mtx),(p)^G_MTX_PUSH,0) http://naesten.dyndns.org:8080/psyq/man/gsp/gSPMatrix.html

Kagaroc: Are you pressing the enter key after entering these values? If not, the values you put in will not take effect.

Just tried it using the first values I suggested, worked perfect. You had them all set to 0. Also, you are missing collision for the door - it should be part of the scene obj file.

It should be something likefront switch [00] cam [FF] back switch [01] cam [FF] OR front switch [01] cam [FF] back switch [00] cam [FF]

Kargaroc: What values did you put in for front switch [__] cam [__] back switch [__] cam [__] ?

Yes. http://wiki.spinout182.com/w/Maps_and_Scenes#Transition_Actors

Woah, impressive. Was it more complicated than matricies on the N64? matricies in badrdp pl0x

That texture doesn't have any transparency. The black/white is the intensity, alpha is a separate channel.

Yep

That just some random hylian charachters or does it translate to anything? Either way I like it - the color scheme especially. Reminds me of some that I did a while back.

Don't quote me on this, but I think Rice's loads them via a CRC of the texture data - so, this assumption being true and assuming they are bit identical would mean that "texture packs" would work with these textures.

A hook is the method used to execute your code - cutting in somewhere in the normal execution of instructions as intended by the original program. In most cases, it is best to do your hook where it is most convenient - for example, if you want to do a hack that needs the address of every spawned actor, you could put a hack at the end of the actor spawn function (as it returns the address of the actor it spawns), by replacing the jr $ra with jal <address of your code>. It is best to hook in or right after a function call, to avoid messing with registers in use. For example, this hook is at the end of one of the custom functions discussed here (specifically, when bb is 0). Now, if you go into RAM and look at what the end of that function looks like unmodified, you will see that I replaced a function call - however, in the function that I replaced it with, I finish that function by calling the function that I originally replaced. I hope somewhat answered your question.

No, the texture in Hyrule Field is a very specific case. Why are you limiting yourself to textures already used in OoT? It's not like it will save space in the ROM. You do know how to make a new material in sketchup, right? If not I'm sure you can find a tutorial on youtube. Go through the temples in OoT and MM, see what tricks they employ to get the feel you are looking for.

Lishy: Did you try the face texture I sent you? Also, the texture you have for the wall (the black fades to blue) is quite nice, but try flipping it - blue on the bottom, black on the top, and then give your model a black ceiling. It will give the effect of disappearing into the darkness. 2009 (though I could have sworn I saw you on IRC within the past year...) we could re assemble actors, it was only fairly recently that the actor disassembler came out - the tools are called nOVL for reassembling actors (working windows binary) and zovldis for disassembling actors. Understanding how I compile all this C to zelda 64 is ... well, I would point you to my makefiles, but they use so much abstraction it is obfuscated unless you know what's going on. I use gcc targeted towards MIPS. It is somewhat complicated to get windows binaries of mips-gcc, however, some prebuilt ones can be found here. While you're at it, I would reccomend getting this MinGW installer. It installs, among other useful things, make, which helps to compile these hacks. Of course, if you use *nix, you probably have make and mips-gcc can be acquired and compiled by getting these scripts and running make.sh. That all being said, I should make a patch of z64-tex-ext As for actor de/recompiling examples: http://wiki.spinout182.com/w/Actors#Custom_Actors All the secrets of the compiling and inserting process are in the Makefiles

I only said that so you could compare the results. Did you try any of my suggestions? If not, try them all, and send a patch with all the changes (including the ones I suggested) applied.

Uncheck the delta box.

Use this kind of patch from now on, please[1]. I'll be glad to help you when I get a moment, though, I probably won't be free for a few hours. A few common things that might screw it up: -Display list jumps [0xDE in display lists] -Multiple headers [0x18 command, replace with 0x01000000 00000000] -Cut scene stuff -MM only header commands [Any header command > 0x19] -Bad collision types [Try setting them all to 00000000 00000000] z64porter does all of this and works 98% of the time, so I suggest you give it a shot.

I hope you mean object - my program wouldn't know what to do with an actor. As for using the mouse to do the translation or rotation [of bones, yes], that is a good idea and I will have to explore ways of implementing it (yay 3D math!) And I tried GTK stuff, and am having some luck.

By command line, do you mean in regards to launching the application? Or using it? Because it can be launched without the command line, but it's own command line is required for some features, though the window hotkeys are considerably powerful. I *MIGHT* look into a GTK GUI. It won't be anything fancy, just a window loaded with buttons and some inputs.

Gonna have to say that I have thought about a GUI and it sounded like a terrible idea to me. Newest build is here, includes SDL dll. I *think* libpng and zlib are statically linked, but it could very well be that they cry of lack of dependencies. If so, you could try googling for the DLLs but I wouldn't reccomend that due to revision differences, just reply that it is giving you hell and I'll upload one with every DLL I can find. https://bitbucket.org/ottehr/z64anim/downloads Latest commit is also in the repository. Thanks for the feedback guys, it keeps my hope (and desire to continue this) up. Also

Hmm, I never ran into that. I must have put SDL.dll in my system32 folder and not remembered. I'll see if I can statically link it.