Register - Login
Views: 87834178
Main - Memberlist - Active users - Calendar - Wiki - IRC Chat - Online users
Ranks - Rules/FAQ - JCS - Stats - Latest Posts - Color Chart - Smilies
12-15-17 12:51:41 AM

Jul - SM64 Hacking - Exploring Camera Data New poll - New thread - New reply
Pages: 1 2Next newer thread | Next older thread
messiaen
Catgirl
Level: 64


Posts: 949/1085
EXP: 2167298
For next: 46799

Since: 11-20-07


Since last post: 3.0 years
Last activity: 2.0 years

Posted on 01-09-11 08:30:28 AM (last edited by messiaen at 01-09-11 08:32 AM) Link | Quote
Decided to collect the camera-related data in this thread and post some stuff I have, since this is currently a
pressing problem with custom levels. Of particular practical interest is Dudaw finding on those general camera
settings used on a per-level basis.

0x8033CBD0: Current camera pointer. There are multiple cameras for a level, this is the one which will be
processed.

0x8033C5A4: Camera distance pointer (32-bit float)

0x80290D90: Function to control camera using second player controller in the ending. (A0 is a pointer to the camera)

In Mario's struct, there is camera-related struct, however its mostly just copy of Mario's parameters that are used by other camera functions. Changing the "camera setting" will trigger a few camera actions.


typedef struct camera_data /* Mario->Camera (0x8033C520) */
{
u32 mario_action; /* copied from mario->action */
float x; /* also copied from Mario struct */
float y;
float z;
s16 _0x10_mario_0x2c; /* 0x10 */
u16 rotation; /* again copied from Mario struct */
s16 _0x14_mario_0x30;
s16 _0x16_mario_0x32;
u32 _0x18;
u16 _0x1c;
u16 camera_setting; /* 0x06 = door opening 0x09 = triggers initial peach animation */

/* incomplete, many other members left ?? */
} Camera;



If I'm not mistaken, after that data there's also some structs containing values such as camera x/y/z rotation and speed.

Originally posted by VL-Tone
First discovery using the checksum less ROM:

With good old ROM corruption, I was able to find a table that seems to contain camera animation pointers.

The table is found at 0xEA4D4 and ends at 0xEA804. Each item in the table is 8 bytes long, the first 4 bytes are a RAM address (0x80xxxx) and the last 4 bytes are some parameters.

The item I first stumbled upon is at 0xEA554, it's the camera settings for when Mario opens (or close) the double doors of the castle lobby (it applies to both inside and outside the castle). By swapping around this item with others found in the table I was able to identify most of them, though some may just not have worked as expected while being used on the door transition.

The most interesting ones are labeled with **, these camera modes follow Mario in unusual ways, and these modes will usually remain active until you enter a painting. The rest are mostly static cameras or non-interactive camera animations. The most interesting camera animations are labeled with %%. The unlabeled items didn't do anything particular, except maybe a few that provided a normal Lakitu camera in the Castle lobby instead of the "stuck in the corner" camera normally found in that room.


80 29 0F 8C 00 46 00 00 -- temporary top down view
80 29 0E 00 00 4B 00 00 -- Pointing somewhere else for a couple of seconds
80 29 0F 1C 01 82 00 00 -- Shows two other places with iris effect
80 29 11 08 00 8B 00 00 -- Crashes while pointing somewhere else
80 29 13 54 02 4E 00 00 -- Crashes while looking up to the sky
80 29 14 2C 00 5F 00 00 -- Shows somewhere else with iris effect
80 29 15 14 01 A9 00 00 -- Pointing somewhere else for a couple of seconds
80 29 15 D4 00 EC 00 00 -- Shows somewhere else with iris effect
80 29 17 74 00 F5 00 00 -- Pointing somewhere else for a couple of seconds
80 29 18 70 7F FF 00 00 -- Stuck 3/4 top down camera
80 29 19 24 00 00 00 00 -- Normal Lakitu cam?
80 29 1C D0 01 68 00 00 -- Zoom out and in on Mario animation
80 29 21 64 7F FF 00 00 -- ** Weird cam follows Mario from very high
80 29 0C 1C 00 01 00 00 -- Normal Lakitu cam?
80 29 0C 30 7F FF 00 00 -- Stuck and static
80 29 91 00 00 01 00 00 -- =======Double door opening======= (Hacked to make this list)
80 29 91 A8 7F FF 00 00 -- Normal Lakitu cam?
80 29 7B 84 7F FF 00 00 -- %% End camera zoom out castle animation with Lakitu flying around. (When everyone says goodbye at the end).
80 29 7C 40 7F FF 00 00 -- Static cam from way down, Mario controls not relative to cam
80 29 91 00 00 01 00 00 -- Double door opening
80 29 91 54 00 1E 00 00 --
80 29 91 F0 00 01 00 00 --
80 29 92 CC 00 32 00 00 --
80 29 93 60 00 00 00 00 --
80 29 91 00 00 01 00 00 --
80 29 91 54 00 14 00 00 -- Points somewhere else shortly
80 29 91 F0 00 01 00 00 -- Castle view when Mario first enters castle ( Bowser message 1?)
80 29 92 CC 00 32 00 00 -- Short zoom on Mario
80 29 93 60 00 00 00 00 --
80 29 91 00 00 01 00 00 -- Double door opening
80 29 91 54 00 1E 00 00 -- Points somewhere else shortly
80 29 94 04 7F FF 00 00 --
80 29 91 00 00 01 00 00 --
80 29 91 54 00 14 00 00 -- Points somewhere else shortly
80 29 94 04 7F FF 00 00 --
80 29 8F E8 00 01 00 00 --
80 29 8D 9C 00 79 00 00 -- Short zoom out animation
80 29 8D 44 00 00 00 00 -- ** Cannon POV cam! Walk slowly (backward) or crouching to move around, and don't jump!
80 29 3C 2C 7F FF 00 00 -- Stuck and static
80 29 3C B0 00 0F 00 00 -- Weird quick glitchy camera movement for a second
80 29 3D 5C 00 00 00 00 --
80 29 42 F0 7F FF 00 00 -- Crash
80 29 43 D4 00 00 00 00 -- Quick Zoom out
80 29 84 B4 7F FF 00 00 -- Zoom on Mario, then stuck and static
80 29 8A F8 00 76 00 00 -- Temporary view from down under
80 29 8C CC 00 00 00 00 --
80 29 8A F8 00 B4 00 00 -- Temporary view from down under
80 29 8C CC 00 00 00 00 --
80 29 8B A0 00 01 00 00 -- Close view from opening door
80 29 8C 2C 00 3C 00 00 --
80 29 8C CC 00 00 00 00 --
80 29 7A 64 7F FF 00 00 -- %% Peach letter!
80 29 7A 38 00 23 00 00 --
80 29 78 4C 03 34 00 00 -- %% Lakitu tour of the castle opening!!
80 29 79 08 01 0E 00 00 -- %% Ciao! Welcome message
80 29 76 2C 7F FF 00 00 --
80 29 4A 14 00 AA 00 00
80 29 4A 94 00 00 00 00 -- from under?
80 29 3E 7C 00 34 00 00 -- from far away for a second
80 29 3E D8 00 00 00 00 --
80 29 3F 70 00 49 00 00 -- from farther away
80 29 3E D8 00 00 00 00
80 29 59 30 00 5A 00 00 -- travels to top view for a second
80 29 3E D8 00 00 00 00 --
80 29 04 40 7F FF 00 00 -- Stuck on side view mario
80 29 57 C8 00 96 00 00 -- Weird fly over animation
80 29 58 94 00 00 00 00
80 29 4C 5C 7F FF 00 00 -- stuck wobbly lakitu cam POV
80 29 54 18 00 64 00 00 --
80 29 3E D8 00 00 00 00 --
80 29 4D B4 7F FF 00 00 -- stuck wobbly lakitu cam POV 2
80 29 4E E8 7F FF 00 00 -- stuck wobbly lakitu cam POV 3
80 29 4F EC 7F FF 00 00 -- **Drunk Lakitu cam follows mario from 3/4 top, controls not relative to cam
80 29 4F EC 7F FF 00 00 -- **same
80 29 52 70 7F FF 00 00 -- **Drunk Lakitu cam loosely follows mario from 3/4 top, controls not relative to cam
80 29 39 44 00 B4 00 00 -- static for a few seconds
80 29 38 6C 7F FF 00 00 -- Bowser message 2
80 29 38 C8 00 00 00 00 --
80 29 24 B8 7F FF 00 00 -- ** Camera circles around Mario
80 29 30 18 7F FF 00 00 -- Stuck drunk Lakitu cam cam from far away
80 29 2A 80 7F FF 00 00 -- **Fish-Eye Mario cam!
80 29 33 8C 7F FF 00 00 -- **Weird backward Mario cam, he always faces the camera, every joystick move will make him go forward in an absolute direction that is relative to the level.
80 29 6F A8 7F FF 00 00 -- Stepping on the wing cap switch message
80 29 83 B4 00 32 00 00 --
80 29 84 58 00 00 00 00 --
80 29 73 B0 00 C8 00 00 -- Goes behind mario for a second, then switches back to normal cam
80 29 84 58 00 00 00 00 --
80 29 67 10 00 BE 00 00 -- From far under when exiting the Castle
80 29 67 C4 00 00 00 00 --
80 29 69 F8 00 78 00 00 -- From far under when exiting the Castle 2
80 29 67 C4 00 00 00 00 --
80 29 68 A0 00 A3 00 00 -- From far under when exiting the Castle 3
80 29 67 C4 00 00 00 00 --
80 29 6B 30 00 78 00 00 -- From far under when exiting the Castle 3
80 29 67 C4 00 00 00 00 --
80 29 5E 8C 7F FF 00 00 -- crash from double door
80 29 5F B0 00 0C 00 00 --
80 29 5F D8 00 00 00 00 --
80 29 61 60 7F FF 00 00 -- stuck and static cam
80 29 62 C8 00 0F 00 00 --
80 29 62 F0 00 00 00 00 --






Originally posted by Dudaw
Hey, here's some good news.
I've found the solution to our camera problems!
@ 0x41C80 [0x80286C80] are some JAL instructions that load the hardcoded "paths" for each of the levels.
The search went exceptionally well; I was expecting something very similar to what I ended up finding.
When I was searching for the RAM offset to where the current camera option is stored, I was somehow led into finding the pointers to the paths.
I haven't checked yet, but I'm sure if we followed our way back from these instructions, we would probably find that camera paths are nothing more than a bunch of elaborate camera positions and rotations.

In case if you didn't notice, the Castle Grounds actually uses a different type of camera setting than every other level. Even when you import a new model into CG, you'll notice that it doesn't seem to follow a path, but instead smoothly rotates around any walls and slopes.
What I did was I took the instruction from 0x41D00 [0x80286D00] and replaced every other one with it.
Only problem I noticed is that the camera position is a little uncomfortable in levels other than CG.
It appears positions and a few other effects must be set somewhere else.

Not only that, but other camera settings such as when Mario comes out of water or goes through a door are in this function, too. Those ones are at 0x41D60.
Also, 0x41C00 [0x80286D00] seems to be for the different camera options that are set with the C and R buttons.

messiaen
Catgirl
Level: 64


Posts: 950/1085
EXP: 2167298
For next: 46799

Since: 11-20-07


Since last post: 3.0 years
Last activity: 2.0 years

Posted on 01-09-11 05:12:20 PM (last edited by messiaen at 01-09-11 06:08 PM) Link | Quote
Some more info on the function Dudaw's pointed out: the later part of it is basically a jump table for camera settings.

The current camera setting can be found at the (global) variable at 0x8033C6D4. Changing this value is the easiest way to mess with camera settings without having to change the tables itself.

0x8033C6D4 is the current camera (u8), 0x8033C6D5 is the previous camera setting.

These camera settings are copied to the current camera (pointer at 0x8033CBD0).

It seems there's a basic camera setting for each level, however a few parts of the levels force different camera settings. For instance, when you climb the stairs at the "Inside Castle" level (area 1), camera setting is forced to 0x0D by function 0x8028E298. Not sure what triggers it (more backtrack must be done).

So, it's quite complex, but hopefully we'll find at least some table with the basic camera settings for each level and a way to disable those forced presets.

Edit: A general list of those 'presets':

0x01 - Bob-omb, Whomps, Tall Tall, Wet-Dry,Tiny-Huge Island, SSL (mostly open levels).
0x02 - tick tock clock
0x03 - Used in the Aquarium
0x04 - Haunted House (0x0d when Inside Rooms)
0x08 - Forced on water
0x09 - Peach Slide
0x0b - Top of mountain in BOB and Bowser Battles
0x0d - Inside castle (When inside a room, 0x04)
0x0e - bowser levels (sort of side view, not many camera rotation changes), rainbow cruise, blue cap
0x10 - Ouside, Rainbow Clouds, metal cap, wing cap, Snow Man's Land, Jolly Roger Bay, Hazy Maze

Edit: After a very boring and long session of backtracking I think I found where the initial camera setting comes from. It's actually from the Level Terrain Geo Layout (function 0x8029AA3C)! Let's see what can be done with that (I'm not very optimistic since there's probably a bunch more hardcoded data involved).
VL-Tone
Member
Super Mario 64 forum moderator
Level: 51


Posts: 589/621
EXP: 953105
For next: 60833

Since: 07-27-07
From: Montreal, Canada

Since last post: 108 days
Last activity: 77 days

Posted on 01-09-11 09:11:51 PM (last edited by VL-Tone at 01-09-11 09:15 PM) Link | Quote
Very interesting stuff messiaen!

I don't have much time tonight to look into the details of this, but one thing I can tell you is that there are many special collision types that trigger camera changes when Mario walks on these areas. I guess that could explain the switch when climbing the stairs inside the castle.
messiaen
Catgirl
Level: 64


Posts: 951/1085
EXP: 2167298
For next: 46799

Since: 11-20-07


Since last post: 3.0 years
Last activity: 2.0 years

Posted on 01-09-11 09:46:21 PM Link | Quote
Easiest way to test this is by changing one byte in the terrain Geo Layout:


|-----> these 3 bytes are actually drawing distance settings
|
0A 01 00 2D 00 [64] [75 30] 80 29 AA 3C 04 00 00 00 0F 00 00 [01] 00 00 07 D0
|
|--> camera "preset"


That will be included in next version of the Level Importer, of course .

Probably there are more hardcoded camera settings than just the "collision type" ones (that might be a secondary reason for having multi-room levels maybe?), but still changing these camera presets has already pretty major effects when it comes to custom levels.
Dudaw
Member
Level: 16


Posts: 6/49
EXP: 17266
For next: 2990

Since: 01-06-11


Since last post: 4.0 years
Last activity: 1.0 years

Posted on 01-10-11 11:17:29 PM Link | Quote
Oh yeah, 0x8033C6D4 is how I found the jump table. Assuming that this would show up as loadword like how a lot of other RAM stuffs are pointed to, I went ahead and searched "C6D4."
There seem to be several of these throughout the ROM followed by pointers to 0x8033C6D5.
I wasn't expecting anything like this, but I somehow ended up where I did.

Anyway, if you don't mind me asking, how do you plan on incorporating camera options into the next version of the importer?
And didya get all of those settings down at 0x80286C80?
Silly me, these are actually different camera settings, not just for levels.
messiaen
Catgirl
Level: 64


Posts: 954/1085
EXP: 2167298
For next: 46799

Since: 11-20-07


Since last post: 3.0 years
Last activity: 2.0 years

Posted on 01-12-11 01:54:28 PM Link | Quote
The level importer will just change that specific byte so that different camera presets can be used.

I am also thinking of writing a custom collision type that changes this camera setting in-game, this way it would be possible to have specific parts of the level with different camera settings. So far, the only level that I found that does that is Bob-Omb Battlefield, actually the Bowser's levels don't use this.

Also, in the Inside Castle, these camera setting changes are probably related to the multi-room system, not to the collision (though this must be checked further).
DarkSpacer
Member
Level: 29


Posts: 66/184
EXP: 132619
For next: 15266

Since: 03-23-10


Since last post: 1.0 years
Last activity: 240 days

Posted on 01-31-11 07:17:43 PM Link | Quote
I did find an interesting interaction when screwing around with the Level Select code...I put up a YouTube video on my channel about it...

http://www.youtube.com/watch?v=GpVA1jKE2z4
Dudaw
Member
Level: 16


Posts: 15/49
EXP: 17266
For next: 2990

Since: 01-06-11


Since last post: 4.0 years
Last activity: 1.0 years

Posted on 01-31-11 08:46:13 PM (last edited by Dudaw at 01-31-11 08:46 PM) Link | Quote
Originally posted by DarkSpacer
I did find an interesting interaction when screwing around with the Level Select code...I put up a YouTube video on my channel about it...


There's nothing too special about that.
If I remember correctly, that's just the camera used when Mario dies... Namely in sinking sand.
There are plenty more silly things you can do with the moon jump code beside that, too.
messiaen
Catgirl
Level: 64


Posts: 967/1085
EXP: 2167298
For next: 46799

Since: 11-20-07


Since last post: 3.0 years
Last activity: 2.0 years

Posted on 02-01-11 10:37:39 AM Link | Quote
Probably even simpler than that, seems like the game is just using Bob-omb's camera.
DarkSpacer
Member
Level: 29


Posts: 67/184
EXP: 132619
For next: 15266

Since: 03-23-10


Since last post: 1.0 years
Last activity: 240 days

Posted on 02-01-11 03:04:48 PM Link | Quote
But isn't that worth some research?

If I'm reading these posts correctly, the camera settings for each level are stored per-level in the level itself (either that or just some separate functions that the camera grabs off-level). If the camera settings can be destabilized by cheats not having anything to do with cameras, shouldn't pointers to those settings be easy to find?

Just saying maybe using a data tracker while having those cheats on would make finding the camera data a lot easier.

Because I've done some more research and screwing around, and found you can use the same method to "steal" the settings from one level and use them in another.

Say you set the Level Select code for Tick Tock Clock, and you enter Snowman's Land. Using the method, the Snowman's Land camera will activate inside Tick Tock Clock.

The only place I've found it not to work is Inside Castle, because for some reason you spawn inside the Secret Slide warp, which then immediately warps you out into PSS and the camera settings don't persist (although I think I've gotten the Big Boo's Haunt camera and BOB's camera inside the castle...I just don't remember how).
Lyskar
12210
-The Chaos within trumps the Chaos without-
Level: 183


Posts: 7871/12211
EXP: 83374438
For next: 1126665

Since: 07-03-07
From: 52-2-88-7

Since last post: 3.0 years
Last activity: 2.0 years

Posted on 02-01-11 03:21:06 PM Link | Quote
Um, you know, that's kind of what they're already doing, except without the cheats.

Please don't bug them with the idea. If your idea is so good, you should be more than capable of figuring it out yourself.

What they know can more or less change the camera data much more than we did before. We don't need you to come in and reinvent the wheel just so you can have your name on it, DarkSpacer.
DarkSpacer
Member
Level: 29


Posts: 68/184
EXP: 132619
For next: 15266

Since: 03-23-10


Since last post: 1.0 years
Last activity: 240 days

Posted on 02-01-11 09:48:20 PM Link | Quote
I'm not trying to reinvent the wheel, I'm trying to find an easier way to locate data. That's as far from reinventing the wheel as you can get. Using the metaphor of inventing the wheel, I'm trying to give them curved wood instead of them trying to figure it out chiseling straight pieces.
messiaen
Catgirl
Level: 64


Posts: 970/1085
EXP: 2167298
For next: 46799

Since: 11-20-07


Since last post: 3.0 years
Last activity: 2.0 years

Posted on 02-01-11 10:00:32 PM (last edited by messiaen at 02-01-11 10:00 PM) Link | Quote
Well, your idea isn't wrong, however there are much more direct ways of looking at the camera problems, that piece of information isn't very useful.

What happens in that code is that even if the level changes, the game still thinks it's on another level, so it uses that camera. However, if for instance we place a read breakpoint in the "Level ID" global variable, there will be dozens if not hundreds of code snippets reading that, so it's not very useful. Better is to place breakpoints on the camera data, especially now that we have located a handful of information about the camera.

Changing a bit the subject, there is another interesting camera discovery I forgot to post here. Some of you may have noticed the "Disable hardcoded Lakitura camera settings" on the last version of the Level Importer (v14). What this option do is to NOP the call to function 0x8028EEB0, which seems to be responsible for many hardcoded Lakitu camera settings, even for instance the top of Bob-omb mountain.

In some levels the effect is remarkable, in others one not so much. Next version of the importer will include a more complex hack in which you'll be able to enable/disable this function on a level basis.
DarkSpacer
Member
Level: 29


Posts: 69/184
EXP: 132619
For next: 15266

Since: 03-23-10


Since last post: 1.0 years
Last activity: 240 days

Posted on 02-01-11 10:12:23 PM Link | Quote
Huh. I guess I should try to actually UNDERSTAND your posts rather than trying to go "This breakpoint does this so maybe this code snippet does this".

That would probably help alot.

(*hides in a corner with an SM64 ROM, Jul, and an axe*)
messiaen
Catgirl
Level: 64


Posts: 992/1085
EXP: 2167298
For next: 46799

Since: 11-20-07


Since last post: 3.0 years
Last activity: 2.0 years

Posted on 02-08-11 10:31:21 PM Link | Quote
Found another interesting global camera "preset" variable 0x8032DF38, which seems to be used for camera turns for instance.
CaptainSwag101
Newcomer
Level: 5


Posts: 2/6
EXP: 509
For next: 20

Since: 08-29-14
From: California, United States

Since last post: 2.0 years
Last activity: 18 days

Posted on 10-23-14 03:12:38 PM Link | Quote
Alright, I know this topic has been dead for a while, but I have some news! Using Cheat Engine 6.4, I found a specific RAM address (I don't remember it off the top of my head, sorry) and opcode (mov [eax+ebx],edx) which, if replaced with NOP, freezes the camera just like the original Mario 64 Movie Maker, and even allows the player to "look around" in first-person mode while still from a 3rd-person viewpoint! My computer uses Windows 7, and I am using Project64 v2.1 for my testing. My only roadblocks with creating and releasing a trainer are that:
1. I'm not very good with Cheat Engine, especially with the form designer, script engine, etc.
2. Even when I find a working pointer to the RAM address I need, when I close the emulator and re-open it, the pointer is no longer pointing to the correct address (I think this is because when I search for pointers, Cheat Engine never finds any static addresses, which are usually colored green and are listed above other addresses. However, I'm not sure what the reason or solution for this is).
3. In order to actually freeze the camera, you need to change the opcode that writes to the camera's position and rotation address, and then restore the original opcode in order to unfreeze the camera again, and I don't know how to modify the address of an opcode in RAM :'(

If anybody here has more experience with Cheat Engine or any of the previously mentioned things, I would immensely appreciate any help!
Kaze
Member
Level: 17


Posts: 41/63
EXP: 21660
For next: 3083

Since: 10-25-12


Since last post: 1.0 years
Last activity: 1.0 years

Posted on 10-23-14 06:27:14 PM Link | Quote
camera data has been decoded for the biggest part allready;

camera data starts at 8033c520 and most important functions are following:

80289684: changes camera position (a0: array[positions]*, a1: pointer to x,y,z float, a2: xpseed?, a3: yspeed, stack+10:zspeed)
8028935C: changes x, y or z position of camera smoothly (a0: position*, a1: end position, a2: speed?)


an example of this being applied is:
https://www.youtube.com/watch?v=ax5ck61mH1k

i've also had success freezing the camera in a spot by copying all of the camera data and recalling it on a specific event (as seen in "Peach's Christams Invitation")
shyguyhex

Level: 14


Posts: 39/45
EXP: 11459
For next: 1612

Since: 01-03-14


Since last post: 2.0 years
Last activity: 2.0 years

Posted on 10-24-14 07:48:56 PM Link | Quote
Originally posted by CaptainSwag10

2. Even when I find a working pointer to the RAM address I need, when I close the emulator and re-open it, the pointer is no longer pointing to the correct address (I think this is because when I search for pointers, Cheat Engine never finds any static addresses, which are usually colored green and are listed above other addresses. However, I'm not sure what the reason or solution for this is).
3. In order to actually freeze the camera, you need to change the opcode that writes to the camera's position and rotation address, and then restore the original opcode in order to unfreeze the camera again, and I don't know how to modify the address of an opcode in RAM :'(


Sort of getting off the rails here but w/e

2 -> Project64 allocates it's virtual console memory dynamically, meaning the memory placement is basically random. You would have more luck with Nemu64 or 1964, as their memory placements are always the same.
3 -> I think Cheat Engine shows the address of each opcode on the left in the dis-assembly view, just make your trainer set the value at that address to 0x90 (which is NOP in x86, if I recall correctly).

I would recommend learning and editing the MIPS asm code instead of doing x86 asm edits to the emulator's recompiled code. Also you might benefit from learning the Windows API functions ReadProcessMemory and WriteProcessMemory, which let you edit the RAM of other programs any way you want.
CaptainSwag101
Newcomer
Level: 5


Posts: 3/6
EXP: 509
For next: 20

Since: 08-29-14
From: California, United States

Since last post: 2.0 years
Last activity: 18 days

Posted on 10-29-14 11:27:29 AM Link | Quote
Thanks for the advice! Also, would it be ok if I sent this info to James Stewart, the creator of the Super Mario 64 Exposed website, so that he could add this info to his site?
Kaze
Member
Level: 17


Posts: 43/63
EXP: 21660
For next: 3083

Since: 10-25-12


Since last post: 1.0 years
Last activity: 1.0 years

Posted on 10-29-14 01:58:36 PM Link | Quote
Originally posted by CaptainSwag101
Thanks for the advice! Also, would it be ok if I sent this info to James Stewart, the creator of the Super Mario 64 Exposed website, so that he could add this info to his site?


yes sure, even though im quite sure he allready knows about that.
Pages: 1 2Next newer thread | Next older thread
Jul - SM64 Hacking - Exploring Camera Data New poll - New thread - New reply




Rusted Logic

Acmlmboard - commit 2f1bc75 [2017-08-27]
©2000-2017 Acmlm, Xkeeper, Inuyasha, et al.

31 database queries, 12 query cache hits.
Query execution time: 0.133687 seconds
Script execution time: 0.018929 seconds
Total render time: 0.152616 seconds