Register - Login
Views: 99798766
 Main - Memberlist - Active users - Calendar - Wiki - IRC Chat - Online users
Ranks - Rules/FAQ - Stats - Latest Posts - Color Chart - Smilies 		05-03-22 06:12:15 AM
Jul - Posts by VL-Tone
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 ... 22 23 24 25 26 27 28 29 30 31
VL-Tone
Member
Super Mario 64 forum moderator
Level: 53


Posts: 144/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days
Posted on 12-22-07 06:15:22 AM, in What Now? A pickable Peach Object? Link
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
Originally posted by yoshiman
It was me who created the pick up Peach code as can be viewed on YouTube (search for yoshielectron). The reason why Peach appears as she should is because I've bothered to include her animation pointer.

One pointer indicates which gfx structure the object uses. And for animated objects you use the animation pointer otherwise you get a messed up object.


Oh, so you're that legendary James guy? Welcome to the forum!

I've known about your site since quite a while, there are many very interesting discoveries on it. I've been thinking of emailing you, but then the laziness bug bit me (it wouldn't be the first time...).

As I understand it, you're specialized in the RAM hacking side of Super Mario 64. Using the Equalizer, which is a super powerful GameShark-type device, you've reverse-engineered some of the mechanics behind the SM64 engine.

But what you've been stumbling on is different from what's edited by TT64, and it's actually a part I don't know much about (except from reading your info). While TT64 edits the level commands in the ROM that place objects in levels, what you've been editing is the "live" variables and parameters in RAM of the objects that are currently in the game as you play it. (You may already know that, but I'm explaining it for everyone else)

The 608 bytes data structures you're talking about on your site don't exist in the ROM as is.

The 0x24, 0x42 and 0x43 commands that TT64 can edit are the macro commands that initialize these data structures as the level is created.

For example, a 0x24 command may place an object at an X, Y and Z position which is essentially, its starting pos. When the level is initialized a 608 bytes structure is created in one of the 240 slots in RAM . Then, the X, Y and Z variables in that RAM structure may change according to the behavior assigned to the object. Note that a level command may create more than one structure thus using more than one slot, for example: the cannon base will spawn the cannon itself as another RAM object, which will itself spawn a bubble object if it's a bubble cannon.

You end up having more control over objects when you edit these RAM variables, because more parameters are available to be modified. For example, the 0x24, 0x42 and 0x43 commands don't include variables for size, but the 608 bytes RAM objects have width, height and depth variables.

While there are ways to edit some geometry layout commands in ROM to change the global size of an object, not all models include a size command, and changes will affect ALL objects of this type. If you changed the Flyguy enemy model to be 10x bigger by editing a geometry layout command in ROM (or scaling vertices), every Flyguy would appear this size in the game. On the other hand, changing the w, h and d variables in the RAM structure can be done on individual objects in the current level, so you could have Flyguys of various sizes.

So the thing is, many of your codes can't be easily transformed into an .IPS (or .PSF) patch, because the ROM level commands are not powerful enough to control all of the same variables, which are generally controlled by ASM functions called by the behavior code.

With some recent discoveries in animation command hacking tough, I could recreate the pickable Peach object mod as a ROM hack.

Still, there are tons of things you've discovered that can be useful to ROM editing and the advancement of SM64 hacking. As we'll begin to understand the mechanism that go from a level command in ROM to a 608 bytes data structure in RAM, it may eventually be possible to create a new "super" level command that can directly set all of these parameters, so we could set up levels with objects like boxes of different width, height and depth, much like the GoldenEye engine is able to do. That will require some ASM hacking for sure, but it would be worth it.

Anyway, maybe a whole thread could be created about hacking these RAM objects, and obviously you're welcome to participate in it

____________________
VL-Tone
Member
Super Mario 64 forum moderator
Level: 53


Posts: 145/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days
Posted on 12-22-07 06:47:30 AM, in Help/Questions about Toad's Tool 64 and SM64 hacking (last edited by VL-Tone at 12-22-07 03:50 AM) Link
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
Originally posted by nevum
Hey guys, just wondering if there is going to be a Vista-compatible TT64 soon


Ask Adobe...
http://www.adobe.com/products/director/special/crossproduct/faq.html


When is the next version of Director software expected to be released?

Adobe has not published an official time frame for the next release of Director and generally does not disclose details of new releases more than 30 days before a product is expected to ship. However, our current planning assumption is that the next major release of Director will be announced in January 2008.


They've just recently changed that tidbit in their FAQ page, previously they were talking about having Director 11 released by the end of 2007. It seems that it will be pushed back, but at least we know we'll have some official announcement this January. I don't think the actual release will be much later than March 2008.

Director was heavily neglected by Macromedia over the last few years, before they were bought by Adobe. Director 11 won't include many new features, even though the last release dates back to 2004. The reason is that most of the work they had to do first is cleaning the neglected and somewhat messy code base. They had to do that anyway mainly because of the fact that they had to port it to intel Macs. While moving Mac apps from PPC to intel was relatively easy for smaller apps, they had no choice but to get to know the program code inside and out, to get rid of the legacy code and hacks. Director 1.0 was released in 1988, and while I'm sure they've did some big rewrite at one point, there's probably a lot of old stuff found in Director MX 2004 (version 10).

They could've done a quick and easy port to Vista (kinda like they did with the Vista Shockwave plug-in) but in a way the intel Mac port forced them to clean up their code so they get a code-base that they'll be able to use to build new extensive features for the next big version (Director 12). So while the intel Mac port may have created a delay for the Vista version, in the end it will be a better thing for both Mac and Vista users.

____________________
VL-Tone
Member
Super Mario 64 forum moderator
Level: 53


Posts: 146/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days
Posted on 12-22-07 06:51:54 AM, in TT64 Version 0.5.9b Released! Bug reports here. Link
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
Originally posted by Garth
All 3 users on my computer are administrators. But TT64 only works on the user that when it was made it was an admin. The other two WERE standard until last week. I re-downloaded it and it still has the same problem.


So TT64 still works on the initial admin account?

____________________
VL-Tone
Member
Super Mario 64 forum moderator
Level: 53


Posts: 147/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days
Posted on 12-24-07 03:53:42 AM, in What Now? A pickable Peach Object? Link
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
There is only one Peach model, but in the geometry layout commands, there are two Peach body part hierarchies. One for the starting sequence where she fades out, and one for the end.

Please refer to this document: http://homepage.mac.com/qubedstudios/PeachGeo.txt and this post: http://jul.rustedlogic.net/thread.php?pid=15523&r=1#15523 for a more detailed description and instruction to make Peach always visible.

There are commands that can write to arbitrary parts of RAM, but they wouldn't be useful for the intended purpose, because we need something that works with the slot allocation system for RAM objects.

For sure there are ASM functions used by the behavior ASM code to set parameters of the RAM objects, that's how for example, the squished Goomba animation can be performed by changing the height parameter of the RAM object. I'm not sure though if these commands can be used.

Yoshiman, when you're talking about the pointer to the behavior coding, are you talking about a pointer that starts with "13" (which is the bank number for behavior scripts)? If so, then this is one of the things that TT64 can edit. You can get a list of most of the behaviors in this doc: http://homepage.mac.com/qubedstudios/SM64Behaviors.txt

Anyway, let's move the rest of the discussion in the "Editing RAM objects" thread.


____________________
VL-Tone
Member
Super Mario 64 forum moderator
Level: 53


Posts: 148/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days
Posted on 12-24-07 04:41:23 AM, in Editing the RAM objects (last edited by VL-Tone at 12-24-07 04:22 AM) Link
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
Originally posted by yoshiman

One of the object variables is a pointer to the behaviour coding, for all we know there might be unused behaviours? This was how, for example, I made a ghost Peach by using the Big Boo behaviour pointer; the behaviour coding can be used in any level. But be warned, some behaviour pointers cause the game to crash if used with certain objects, this may be due to the coding finding values within the object structure that it doesn't 'like.'

I really need to look at the ASM in more detail, see how it handles the object behaviour. Compared to Ocarina of Timer and Resi Evil 2 on the N64 that I know quite a bit how the objects are handled, SM64 although simple has features that perhaps were planned to be used at one time. For example, you can rotate an object's collision idependent of the actual object rotation so you can, for e.g., read only the back or side of a signpost.

We really need to take SM64 apart, I'm sure there is something hiding...

James S.



As I've said in the other thread, if the behavior pointers are the same as those that are set by ROM level commands, you might be interested in this document: http://homepage.mac.com/qubedstudios/SM64Behaviors.txt

The behavior pointers (13XXXXXX) refer to what I've called "behavior scripts" which are a few commands that set different aspects of the behavior for a given object. Behavior scripts can, amongst other things, set the animation sequence of an object (using the 0x27 command). The 0x27 command is described in more details in this thread: http://jul.rustedlogic.net/thread.php?id=954

Other behavior commands include one to set the collision map of a single object (0x2A) and other commands can spawn sub-objects (0x1C, 0x29 and 0x2C). The 0x0C command calls ASM routines found in RAM, and this is where the real magic happens. 
[0C] [00 00 00] [80 2A CC 3C]



[0]= 0C is the command byte.

[1,2,3]= Always zero, unused?

[4,5,6,7]= Offset in RAM of the ASM function.


I haven't studied much of the ASM routines that are referred by the 0x0C commands, but once we reverse-engineer most of it, we'll be able to do very interesting stuff.

Originally posted by yoshiman
I know a lot about the so-called 'RAM objects,' I'm putting a list together about the different variables that belong to a structure. From what I understand, the level details only set a few of the variables such as position and rotation, very much as is the case of Ocarina of Time. However, the level details are copied to the RAM in Ocarina of Time but this does not seem to be the case for SM64.


At which address the RAM objects are stored?

The ROM level commands are also copied to RAM in SM64, like in OOT. I guess you just didn't stumble on them.

Originally posted by HyperHacker
I doubt that's really support for planned but unused features so much as just quirks of the way it's programmed. Many games have collision maps and actual level models separate for speed reasons (the collision map can have much less detail/fewer polygons since it's invisible), so you can make them mismatch if you want.
Originally posted by yoshiman
But be warned, some behaviour pointers cause the game to crash if used with certain objects, this may be due to the coding finding values within the object structure that it doesn't 'like.'
I'd guess it's more likely the code tries to reference a part that isn't in that model.


We're still looking for the Blargg behavior script. There's still a lot of undefined and un-referenced behavior scripts so there's still hope. I also more recently found the animation command pointer for the Blargg: it's 05 00 61 6C. So not only the model is still there, but also the animation data.

Some behavior scripts are dependent on data that's only present in certain levels. Those include behavior scripts that refer to collision data found in a specific memory bank (segment), or those that refer to animation data.

While some object indeed have polygonal collision maps (levels, platforms, boxes etc.), many enemies and Mario himself don't use polygons for collision detection. Because of the complexity of the body, and the fact that it's animated, a spherical collision bubble is instead used. There's no polygon involved, it's only a matter of detecting a collision if the distance between objects is less than X. This is how most 3d games worked until more recently when more powerful and precise physics engines were implemented in games.


Just a little note, the current thread is a related to this thread: http://jul.rustedlogic.net/thread.php?id=1607 (which was trashed).

yoshiman (aka James S.) is an experienced SM64 "RAM hacker" that can bring a lot to the SM64 hacking community because of his discoveries. More on his website at http://james.boshikoopa.googlepages.com/game_codes and http://james.boshikoopa.googlepages.com/game_hacking


____________________
VL-Tone
Member
Super Mario 64 forum moderator
Level: 53


Posts: 149/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days
Posted on 12-24-07 05:00:09 AM, in Future uses for a possible level geometry/collision map editor Link
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
I was about to write something about explaining why Mario couldn't walk upside-down in SM64, but then I realized that this is not what you were talking about.

Flipping a level upside-down could be done without a complete geometry editor program. Just find the vertices list for both the geometry and collision map, and invert the Z parameter (and maybe add a number to it to modify its vertical offset).

As for this topic, I think it will just create too much hype and expectaTION for a tool that doesn't exist or isn't released yet, detracting attention from what TT64 can do now.

There's tons of fun stuff to do with TT64, and tons of things that are still waiting to be discovered with TT64. If people only focus on what TT64 can't do, they'll only be longing for something, instead of appreciating what they have now.

____________________
(post in restricted forum)
VL-Tone
Member
Super Mario 64 forum moderator
Level: 53


Posts: 151/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days
Posted on 12-24-07 05:49:50 AM, in Japanese TT64 site (last edited by VL-Tone at 12-24-07 03:27 AM) Link
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
Japanese people have been discovering Toad's Tool 64 lately, as it seems that a well-known Japanese magazine (Windows%100) featured an article about it. It's only natural that they're interested in TT64, because after all Super Mario 64 is a Japanese game!

As discussed previously, my M64 ROM Extender unfortunately doesn't work on Japanese Windows systems. The solution they've found is to create a "difference patch" to extend the ROM. It's in the form of an executable, so that it includes both the patcher program and the patch itself. I've uploaded the program to my website if you want to check it.

http://homepage.mac.com/qubedstudios/JapaneseM64ROMExtender.zip

People using foreign Windows system and/or anyone having problems with my ROM extender might want to try it.

There's a now pretty extensive "atwiki" Japanese page about TT64.

http://www41.atwiki.jp/ttmario64/

Here's the translated version:
http://www.google.com/translate?u=http%3A%2F%2Fwww41.atwiki.jp%2Fttmario64%2F&langpair=ja%7Cen&hl=en&ie=UTF8

Amongst other things, there's a page with a few mod patches http://www41.atwiki.jp/ttmario64/pages/26.html Again they're mostly .exe files (I'm not sure if they're supposed to be applied to an unextended or extended ROM).

There's another page with a long list of videos of Japanese SM64 hacks made with TT64:

http://www41.atwiki.jp/ttmario64/pages/35.html

It seems that there's a lot of SM64 hacking activity over there, I wish I could read Japanese and didn't have to use online translators!

Edit: The videos are on nicovideo.jp which is a Youtube-like japanese site that requires registration to view the video. To register, follow the instructions found at: http://www.neogaf.com/forum/showthread.php?p=8551398

To disable the scrolling comments, click on the little bird icon found at the bottom of the player.

____________________
VL-Tone
Member
Super Mario 64 forum moderator
Level: 53


Posts: 152/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days
Posted on 12-26-07 05:19:22 AM, in Future uses for a possible level geometry/collision map editor Link
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
Ok then, dream on guys...

Just don't beg for the geometry editor, and keep in mind that there's still lot of fun things that can be done with TT64 as is, just check out the Japanese mods.

____________________
VL-Tone
Member
Super Mario 64 forum moderator
Level: 53


Posts: 153/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days
Posted on 12-26-07 06:05:51 AM, in Japanese TT64 site Link
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
I've been watching the Japanese SM64 mods videos over the last few days (I was only aware of the main page, I didn't realize it was a full site with videos and patches until I created this topic). Some of them are really interesting and creative. One even features an "automatic Mario" segment in a Bowser stage http://www.nicovideo.jp/watch/sm1059340

Some mods were made by SM64 pros who created extremely hard levels and goals, and you can see them jumping around with no hesitation on small platforms high in the sky, very impressive stuff.

I think that the average age of the Japanese SM64 hacker might be higher, because of cultural differences. While north-american players in their twenties might have grown disinterested in SM64 and moved to more "mature" stuff, Japanese have been exposed to much more cute and cartoony stuff. So I would think that there's a smaller amount of immaturity in their SM64 hacking community.

Originally posted by HyperHacker
Interesting, I wonder why it doesn't work on Japanese systems? Text doesn't show up, or it doesn't run at all?


The ROM Extender simply doesn't work as intended on Japanese systems. The resulting extended ROM would be unusable, and simply reading the checksum fails so you can't even manage to get to that point.

Here's why:

To enable fast copying of large binary data chunks in Director MX, I had to use the Binary IO Xtra, which is a plug-in for Director. The built-in File I/O Xtra is not suited for binary data I/O.

The Binary IO Xtra can quickly read large amount of data directly into a text variable. I'm using the Binary IO Xtra to copy the decompressed MIO0 banks into the extended ROM, loading them into a variable, and then writing the data back directly from the variable.

The problem is that on a Japanese system, Director MX uses a different internal representation of text variables (Unicode) which as a result corrupts the data read from the Binary IO Xtra (for some reason, some bytes end up being skipped).

TT64 itself uses a different Xtra to read/write data, which is slower and read data in list variables that look like that [255,0,0,120,232,34,50]. So TT64 works on Japanese systems, but not the ROM Extender. I could retrofit the other File Xtra into the ROM Extender, but it would end up being much much slower. Anyway there are other problems with the ROM Extender, one being that it doesn't work with WINE on Linux (but TT64 does.)

Anyhow, Cellar Dweller has been kindly working on a new cross-platform ROM Extender written in C (which will work in Windows, Mac and Linux). He already gave me a working command-line prototype, and he intends to add a GUI.


____________________
VL-Tone
Member
Super Mario 64 forum moderator
Level: 53


Posts: 154/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days
Posted on 12-26-07 07:09:26 PM, in Japanese TT64 site Link
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
Originally posted by Kles
Originally posted by HyperHacker
Er, how do you watch the video? I only see a thumbnail.



Gotta register. Look up on Google how to do it. (register nicovideo or something)



You can google it, or you can take a look at the last link in the first post of this thread.

____________________
VL-Tone
Member
Super Mario 64 forum moderator
Level: 53


Posts: 155/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days
Posted on 12-27-07 04:38:40 AM, in Hacking animations Link
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
yoshiman, you might want to take a look at this thread: http://jul.rustedlogic.net/thread.php?id=954

What I'm describing there is the 0x27 animation command used in the behavior scripts. The command includes a pointer to animation data which is found in the same MIO0 (compressed) data bank as the geometry for a particular animated object.

I didn't spend much time on analyzing the format of the animation data, but it seems to be related to the animation values you're talking about. It contains a series of rotation values, arranged in a hierarchy that matches the body hierarchy.

But Mario is a special case, its behavior script doesn't contain a 0x27 command, and I've found no traces of animation data anywhere in Mario's MIO0 data bank. In fact it's behavior script doesn't seem to be used that much, you can change values and things, and the only difference you'll see is that for some reason Mario will run faster. Aside from that, he seems to be controlled by an entirely different animation system.




____________________
VL-Tone
Member
Super Mario 64 forum moderator
Level: 53


Posts: 156/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days
Posted on 12-27-07 04:41:43 AM, in Japanese TT64 site Link
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
Originally posted by HyperHacker
Originally posted by Kles
Originally posted by HyperHacker
Er, how do you watch the video? I only see a thumbnail.



Gotta register. Look up on Google how to do it. (register nicovideo or something)

Booooooooo.


Yeah, it's a drag, but nicovideo contains a large collection of very nice video-game related stuff (amongst other things) that you usually can't find on Youtube. I guess that registration is a way to prevent the site from being invaded by stupid westerners

____________________
VL-Tone
Member
Super Mario 64 forum moderator
Level: 53


Posts: 157/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days
Posted on 12-27-07 04:44:37 AM, in SM64 RSP Commands Link
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
I guess that moving models from SM64 to SMK64 would be easier than in the opposite direction?

____________________
VL-Tone
Member
Super Mario 64 forum moderator
Level: 53


Posts: 158/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days
Posted on 12-27-07 05:38:15 AM, in Editing the RAM objects Link
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
Originally posted by HyperHacker
Originally posted by yoshiman
Am I right in thinking that the lower polygon Mario is used for collision purposes or is it the original model left in?
I'm pretty sure it's for when Mario is far enough from the camera that most of the detail would be lost. A lot of games will use low-polygon models for far-away objects since you wouldn't notice it at that distance anyway.


Yeah it's a LOD (level of detail) system, but it only applies to Mario. There are actually 3 different Mario models. TT64 includes a feature to disable the low-polygon Mario and use the high-poly version in all cases, and somehow it doesn't seem to slow down the game.



Ok, so I've done a little RAM searching with the latest version of PJ64, and I've found the 608 bytes long RAM objects and did some experiments.

When in the Castle Ground level (NTSC version, which is the only one I'm gonna refer to), at 0x8033D6E8 in RAM you can find the data structure of a tree. This tree in TT64 is the 2nd object in the 0x43 list (the first being the Castle Tower).

At 0x33D788 you can find the current X Y and Z coordinates (and size?).

But the most interesting find was what yoshiman call the behavior pointers. To avoid confusion, we should use a different name since in TT64 it means something else.

Let me explain:

In the level setup commands found in ROM (and also copied in RAM), the behavior pointer for a tree is 13002AA4. It's a pointer for a behavior script, found at offset 0x2AA4 in bank 0x13

Here a quote from this doc: http://homepage.mac.com/qubedstudios/SM64Behaviors.txt

Behavior scripts are loaded in bank 0x13. They define some basic parameters an object behavior. The core of the behavior logic though is in ASM functions, which are called by the behavior scripts using the 0x0C command.


Bank 0x13 is copied to RAM from location 219E00 to 21F4C0 in ROM. The location in RAM of bank 0x13 is dependent on which other bank was loaded before, though I think that the banks loaded before are usually the same since these are shared by most levels.

So, to get back at this tree behavior script, here's what it looks like: 

ROM Addr: 0021C8A4 Hex Behav: 13002AA4

Description: Tree Behavior

21C8A4/002AA4  00 0A 00 00

21C8A8/002AA8  21 00 00 00

21C8AC/002AAC  11 01 00 01

21C8B0/002AB0  10 2A 00 40

21C8B4/002AB4  23 00 00 00 00 50 01 F4

21C8BC/002ABC  10 05 00 00

21C8C0/002AC0  08 00 00 00

21C8C4/002AC4  0C 00 00 00 80 2C 63 E8

21C8CC/002ACC  09 00 00 00


The only command I know really in this particular script is the 0x0C command. It points to an ASM function in RAM (at location 0x802C63E8 in this case) where the actual behavior code is executed.

While experimenting in the 608-byte RAM object, I've found what yoshiman call the behavior pointer in this case: 0x80EDC44.

The pointer is found at two places in the 608 bytes structure, at 0x8033D8B4 and 0x8033D8BC.

Here's the interesting part, if you look at the location referred by the pointer (0x80EDC44), here's what you find:

80EDC44: 0C 00 00 00 80 2C 63 E8 09 00 00 00

Looks familiar? It's the 0x0C command found in the tree behavior script! And actually, the whole script is there, in fact this location is part of bank 0x13 in RAM.

In some object behavior scripts, there are more than one 0x0C commands, so that explains why yoshiman found objects that had multiple "behavior pointers".

I hope it's not too confusing...

To summarize, there are pointers in RAM object that refer to 0x0C command locations found in bank 0x13 in RAM. These pointers are probably set up while the level is created, and the behavior script for each object is read the first time. The 0x0C commands themselves refer to ASM functions found elsewhere in RAM.



Ok that's about it for now, I'm going to be in vacation for a week or so, with no or little internet access, in the meantime, please be kind to Metal_Man88

____________________
(post in restricted forum)
VL-Tone
Member
Super Mario 64 forum moderator
Level: 53


Posts: 160/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days
Posted on 01-04-08 02:29:32 AM, in Super Mario 64 Saga Link
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
Originally posted by GlitchGuy2
A series of terror for Mario, SM64S, is a 40 minute long saga I worked on a while back.
Here is the episode
http://youtube.com/watch?v=uPOK9m1bJ0A\
http://youtube.com/watch?v=qkBQ3_Ys29Y&feature=related
http://youtube.com/watch?v=0CqB_sxPhS0&feature=related
http://youtube.com/watch?v=Ve7xoui345M&feature=related This one has no sound

I''m afriad I lost the ROM to this though... Sorry.


Please use the appropriate thread to post your mods or videos. Post your SM64 mods, patches and screenshots here!

You might also want to do some research and learn how to post url addresses on a forum.

This thread will self-destruct in a few hours...

____________________
VL-Tone
Member
Super Mario 64 forum moderator
Level: 53


Posts: 161/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days
Posted on 01-04-08 02:50:56 AM, in TT64 Version 0.5.9b Released! Bug reports here. Link
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
Originally posted by kingwhomp
VL-Tone...,i just had a question...do u know when TT64 will be updated???

Hello, I'm back from my vacation!

Well I can't blame you for asking, since I was supposed to update TT64 a while ago (even though I never gave any specific date).

I didn't work much on TT64 over the last couple of months. Mainly because I had less time. But another reason is that since I upgraded my Mac to OS X 10.5 (Leopard), Director MX (the program used to make TT64) has a big problem. Every other program I have work perfectly under Leopard, but lucky as I am, only Director MX has a problem. The worst part is that others seem to have no problem running Director under 10.5.

Everything works fine, except for one thing: keyboard shortcuts (for menu etc.) stopped working. And it's a pain, since I'm really used to them.

I was waiting for Director 11, the next version (Vista and intel-Mac native) which was supposed to be released by the end of 2007, but the release has been pushed back, as I wrote elsewhere, the release date will be officially announced this month.

So I've been a little reluctant to work on TT64 since then, because it would require me to either dual-boot with Tiger (10.4) or fire up Parallels (Windows VM) each time I feel like working on it. And Parallels runs a little slow when it comes to some of the 3d stuff.

I may still release version 0.6b it before Director 11, because it's been a long time since I've released something, and some of the features of 0.6b were already in the work when I stopped working on TT64 (saving/loading individual levels, reverting to original ROM data)

____________________
VL-Tone
Member
Super Mario 64 forum moderator
Level: 53


Posts: 162/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days
Posted on 01-04-08 03:03:16 AM, in SM64 Music Editing Link
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
Originally posted by matalilo
I've made some research on the Mario 64's sequenced format and just didn't find somthing nice out, but I am working on a decompiler for midi export!

It seems the seq file(s) are not the same as those compressed with "midicomp".

Just now I did somthing in N64 programming and compiled after one day of
messing with the compiler stuff a midi player for the n64! It uses the general midi soundbank and an uncompressed midi-file.

I tested the programm on PJ64 v 1.6 with it's provided plugins /Sync to Audio = on!

I'm working on a new version with improvments like compressed midi, text/video stuff for playback info.

I'll post more info very soon

Link http://uploaded.to/?id=l37mdm (whenever the link should not work just scream

.matalilo


matalilo for some reason your post was completely overlooked by everyone here (including me), even though that midi decompiler project of yours looks promising. I hope you were not discouraged by the lack of replies If you read this, please come back, we need more smart people here

Originally posted by mortalkenshi2
well i went and looked through this data and i looked up the title screen music. I deleted it and replaced with Bob-omb battlefield music and it played really glitched up. It was playing the song but like the main melody was like really deep. Also, I looked through the zelda rom for the addresses that rstewart showed and I didn't really find anything. Can anyone help me out?


I guess it's simply because the instruments and settings for this tracks are different. As for Zelda, maybe the addresses are for different version?

____________________
VL-Tone
Member
Super Mario 64 forum moderator
Level: 53


Posts: 163/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days
Posted on 01-05-08 11:15:08 PM, in Editing the RAM objects Link
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
Originally posted by yoshiman
Yeah, the behaviour pointerss are nothing more than jumps to ASM, that is, coding stored in the RAM. But since that's copied from the ROM, it would be possible to alter how objects behave. I mean, create new behaviours, such as for Mario to ride Yoshi.

James S.


Mario riding Yoshi would be pretty nice, we're not quite there yet, but your info certainly help us move in that direction.

What else can you tell us about the RAM objects? It would be very useful if you could make a list of the variables/parameters you know about.

____________________
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 ... 22 23 24 25 26 27 28 29 30 31
Jul - Posts by VL-Tone


Rusted Logic

Acmlmboard - commit 47be4dc [2021-08-23]
©2000-2022 Acmlm, Xkeeper, Kaito Sinclaire, et al.

33 database queries, 41 query cache hits.
Query execution time: 0.074949 seconds
Script execution time: 0.084948 seconds
Total render time: 0.159897 seconds