spinout

Climb all walls: 81041DA8 3402 81041DAA 0004 Bomb arrows: Print z-targeted actor info: Tool Mode Vowel replacement (vowels => os in dialog) Lots more: http://wiki.spinout182.com/w/Debug_ROM:_GameShark_Codes http://wiki.spinout182.com/w/Debug_ROM:_Weather_Codes http://wiki.spinout182.com/w/Interface_Hacking http://wiki.spinout182.com/w/Category:GameShark_Codes (mixed games)

JSA: I don't know if you've tried this or not, but you might want to give objn64tool a shot. Try setting the base address to something like 0x03000400 - whatever the offset would be in a map at the end of the mesh data header. Then take the output and stick it at that address in a map, and point the mesh data header to the proper address.

Those 0xFD commands are the pointers. The palette is loaded, then the image is changed to the pointers you mentioned in code.zdata. The colors in each of link's face textures are the same, therefore, only one palette is needed. It is the arrangement of the colors that is changed with the pointers in code.zdata.

Whoo! https://bitbucket.org/ottehr/libbadrdp_r-lmem32-lobj/changeset/9fd812f3723e This is very good news. Once I work any potential bugs out z64anim progress will continue. Obj exporting is handled very differently in this fork of badrdp.

re: Hobby/money: I always tried pursuing 'hobbies' which required money despite not having much money. If the internet is failing you in supplying money and or a hobby, see what you can do for little money off of the internet - build forts out of old/scrap wood, make art out of "garbage". A few things off the top of my head: - bow and arrow - nylon string and a springy piece of wood (bamboo works well). Basically free, and can provide hours of entertainment - carve things out of/into wood - just requires some sort of knife & patience - cut & shape aluminum from old soda/beer cans into flowers, animals etc - you might be able to sell this kind of stuff too. Based on what I've seen you do, you have a mind with plenty of potential and ability to do things of this nature. re: Fitness, I am not the person to ask about this. The suggestions in this thread look like a good place to start, though. It isn't so pressuring. A lot of things that people would usually say are reserved for "cool" people really are more misconceptions in people's minds about what other people think. This isn't very clear, perhaps an example would help to illustrate my point: When surveyed, most college students thought that most (> 50%) college students were regular-heavy drinkers, when in actuality, less than 20% are regular-heavy drinkers. This applies to many of the pressures you've been experiencing in social environments, and will continue throughout your education, if not further. Learn to ignore it and listen to your inner desires - they should be your ultimate guide. Be yourself. Maintain your friendships. You have a lot of potential.

Assembly really isn't that bad. And learning C (thoroughly) will be the greatest thing you ever did. I guarantee it.

The length does not matter. As for the RAM address, that is for you to figure out. You would have to do some sort of ASM hacking to get the RAM address - maybe code that DMAs the data from ROM -> RAM. Therefore, the command would have to be written directly to the main display list. From my experience, there are actually two main display lists. Given the global context, writing a display list command in form word0,word1 to it is implemented as such: void dl_write( void *z_ctxt, uint32_t w0, uint32_t w1) { uint32_t *dl_ptr; /* The game seems to use multiple main display lists.. */ dl_ptr = (uint32_t*)*(uint32_t*)(*(uint32_t*)(z_ctxt) + 0x2C0); *(dl_ptr++) = w0; *(dl_ptr++) = w1; /* Update the pointer or the changes will not be saved! */ *(uint32_t*)(*(uint32_t*)(z_ctxt) + 0x2C0) = (uint32_t)dl_ptr; /* The other display list */ dl_ptr = (uint32_t*)*(uint32_t*)(*(uint32_t*)(z_ctxt) + 0x2D0); *(dl_ptr++) = w0; *(dl_ptr++) = w1; *(uint32_t*)(*(uint32_t*)(z_ctxt) + 0x2D0) = (uint32_t)dl_ptr; } In other words: Get the pointer at (global context + 0x2C0). Write the display list command at that address. Increase the pointer at (global context + 0x2C0) by 8. Do the same at the pointer at (global context + 0x2D0). I will attempt to implement a hack which creates bank 0x0F which would be full of weapons.

Yes, very possible. Just use some display list commands: DB0600xx pppppppp E7000000 00000000 x = bank * 4 p = RAM address of bank I did a hack called z64-tex-ext which used this to .

The goron bracelet is actually 0x06016118, but I didn't find any pointers to it. It is probably part of an lui/addiu pair.

It is in ovl_Effect_Ss_Stick.ovl.

re: .x file format, the spec is here. Way more complicated than obj or xml. Though it is more powerful than obj. I'm not sure what kind of licencing it is under, either. *ponders writing a library*

The base address option should take care of you. Try something like 0x06001D00.

Most that stuff should be available here. Have at it.

Whoo! Activity. Crashes when exporting obj: Is it generating PNGs? I think it has something to do with libpng not working properly. I... don't know what to say about this one. I am working on making z64anim libmem32 compliant, but that requires making libbadrdp libmem32 compliant, which is quite a big task, one that I have only a start on. libobj-lmem32 is pretty much done however. As for the saving, I need to redo all the saving and loading routines. This will come after or with libmem32 compatibility. Seeing as there is interest in z64anim I will prioritize it over some other projects I've been working on recently - I've been making models for Goldfinger64.

Yes. Many programs confuse between the two or accept both. The obj/mtl format isn't very strictly followed in many programs, all my importer/exporters up to libobj included. libobj, on the other hand, is very, very strict in it's obj parsing methods.

Editing collision types is relatively simple. Just find the jump table.

Read and understand this article.

Oh, xdaniel. I don't know if you're aware of this but I forked badrdp in hopes of making it reentrant and compatible with my other libraries - libobj and libmem32. I'm doing this so I can eventually make z64anim work with libmem32 - the advantage of libmem32 being that it keeps track of pointers when adding and removing bytes. Weather or not you are interested in this fork, I don't know, but it is neat in the sense that it is (supposed) to be reentrant - which gives some advantages, I guess, if you are rendering multiple ucodes at once or something.

I hate myself for nitpicking but why are you saying it 'MOD'? Why not just mod? When I see ALLCAPS I think it is either yelling or an acronym - an acronym in this case. /rant Anyways you should (if you haven't already) organize all the files and document everything you've done so it is easy to share by whatever means you end up deciding. I sure do hope you finish this modification.

Did you ask for any help/provide any feedback? I'd be glad to help people use my programs.

It isn't really a big secret. Talk to jrra in #n64dev on irc.efnet.org

I'm talking about objn64tool.

I feel like all my code goes unused because I write command line applications.

JUST so everyone knows that app is mupen64plus with a frontend. The author is a totally evil guy because he didn't comply with the (open source) licences which mupen64plus is released under - he easily made $50,000 on about 2000 lines of his own code. :grumble grumble:

Vertex colors are not always vertex colors. Depending on the Geometry Mode command, they are either vertex colors or vertex normals. When they are normals, the values are not RRGGBBAA, but they are XXYYZZ00 (iirc - I'm no pro with normals) - and they are calculated in a similar fashion to collision normals. When they are vertex colors, they are used for coloration - an example of this can be found in the temple of time, or the item test dungeon (119).