Completed Follow Camera that follows base position (topN)

[schmooblidon]

In develop mode, there is the camera mode toggled with up that locks onto the character and follows them. Training mode seems to also use the same thing for it's Zoom and Free mode, but I'm only concerned with develop's camera as I can change the perspective.

Right now the camera doesn't follow the base position, seems like it's following either a particular bone or their center. I need it to follow topN.

Thank you in advance, you will be a true homie!

Edit: Thought I'd talk about what I want this for, so whomever is interested knows what their efforts will accompolish.

I've been developing a web based melee clone for about a month called Melee Light. To make marth's animations, I had to take a screenshot of each frame with environment collision boxes visible. Go through each frame and cut out a path, also including a point to the base position. Then export these paths to illustrator where I place them in the top left corner, such that the base position marker is 0,0. Then save them as an svg, copy the path's d attribute and plug them into an array. Then convert that path to an array of points, so that canvas can easily understand them and draw it out fast.

It is a tonne of RSI inducing work, and the reason why I only have marth done (not even 100% done). Recently I've discussed new methods to grab the animations with a couple of peeps. And we can up with a workflow that is 50x faster and produces really crisp paths and simultaneously sprites.

The workflow for this goes like this; Green screen the backdrop, set the camera to follow the base position, take a screenshot of each frame. Take 1 screenshot of the base position (need only 1 reference for the entire char), open all frames in gimp and use magic wand to cutout the char. convert selection to path with a high-ish tolerance so it's not crazy detailed (and therefore laggy), save as svg as one file for a whole action state. run the script i wrote to convert the whole animation into ready to use arrays of points.

With this method, we can create both this sprite based animation

and this canvas based animation

all in only about 20 mins of work.

As you can see the camera is the missing piece of the puzzle, but unfortunately I'm a scrublord when it comes to memory address stuff, and writing codes is way out of my league.

 

[Punkline]

Sweet project! Good luck with this.

I did some digging. Will this code work? It should only apply to the developer mode zoomed camera:

$Zoomed Developer Camera Focuses on TopN [Punkline]
C2086704 00000005
3CE08045 60E72C6C
80E70000 28070007
40A2000C 38000000
48000008 8003016C
60000000 00000000

Spoiler: MCM Injection Mod

    -==-


Zoomed Developer Camera Focuses on TopN
[Punkline]
Version -- DOL Offset ------ Hex to Replace ---------- ASM Code
1.02 ----- 0x80086704 --- 8003016C -> Branch

3CE08045 60E72C6C
80E70000 28070007
40A2000C 38000000
48000008 8003016C
00000000

Spoiler: ASM

/* Zoomed Developer Camera Focuses on TopN [Punkline]
@80086704: lwz    r0, 0x016C (r3)  (loading the boneID of player bone to pass to camera function)
r0, r7-r12, cr0, lr are safe
--load camera state (static address 80452C6C)
--if state == 7, then camera is in zoomed developer mode camera
--use this to tell the game to use boneID 0 rather than loading WaistN for the chracter
*/
lis r7, 0x8045
ori r7, r7, 0x2C6C
lwz r7, 0(r7)
cmplwi r7, 7            #check camera mode
bne+ default
li r0, 0                #boneID 0 == topN
b return
default:
lwz r0, 0x16C(r3)       #original instruction loads normal bone for camera
return:

Spoiler: Notes

The game references the camera state with a static address (80452C6C.) When the state is == 7, it’s in developer zoom mode.

The game stores a reference of the player bone used for the camera at internal player data offset 0x10C -> 0 -> 0x16C. Changing this, or intercepting the game loading this value will allow you to select a new bone for the camera to focus on. Specifically, it's used with internal player data offset 0x5E8 to get a pointer to a specific bone.

The character attributes at internal player data offsets 0x27C and 0x280 seem to be related to this.

My comments on some functions involved in the common action state camera logic function that helped me find this info.

 

[schmooblidon]

Sweet project! Good luck with this.

I did some digging. Will this code work? It should only apply to the developer mode zoomed camera:

$Zoomed Developer Camera Focuses on TopN [Punkline]
C2086704 00000005
3CE08045 60E72C6C
80E70000 28070007
40A2000C 38000000
48000008 8003016C
60000000 00000000

Dude it works perfectly! Thank you so much for your time, this kicks ass!

 

[Achilles1515]

That gif looks amazing, schmooblidon . Looking forward to seeing more of this. And nice code, Punkline .

 

[DRGN]

I've written automation that integrates with Dolphin to capture characters' move/animation frames. I've also written some plug-ins and macros for GIMP for post processing the frames to give them a transparent background and crop them. I believe I've talked with you about the project I created these for before, schmooblidon ; but it sounds like you're looking for a really similar image database. It's been a while since I've worked on all of that though, so I'd have to look into it all again. If I recall correctly, it still needed some tweaks but was mostly all automated, besides needing to manually change characters. I might just be able to create the entire image database you're looking for.

I made my own camera mode for this quite some time ago, but the automation would also work with Punkline's code. I'm eager to try that out. I really need to finish my current work on MCM and some other things first though. XD

 

[schmooblidon]

I've written automation that integrates with Dolphin to capture characters' move/animation frames. I've also written some plug-ins and macros for GIMP for post processing the frames to give them a transparent background and crop them. I believe I've talked with you about the project I created these for before, schmooblidon ; but it sounds like you're looking for a really similar image database. It's been a while since I've worked on all of that though, so I'd have to look into it all again. If I recall correctly, it still needed some tweaks but was mostly all automated, besides needing to manually change characters. I might just be able to create the entire image database you're looking for.

I made my own camera mode for this quite some time ago, but the automation would also work with Punkline's code. I'm eager to try that out. I really need to finish my current work on MCM and some other things first though. XD

Holy hell please share. This could literally be the difference between a months work and a days work.

 

[DRGN]

Holy hell please share. This could literally be the difference between a months work and a days work.

Sure. I'm going to post regarding it in the conversation about that other project relating to frame captures, since I think both projects could probably benefit from it. Either from the same raw files but with different post processing (so everything would only have to be collected once), or with tweaks made to the base process for collection, such as swapping the camera code.

 

[DRGN]

I've recently been going through some of my old codes for an old frames project, and thought I'd post one of the codes if anyone might find it useful. This one is pretty similar to Punkline's, but it follows the center of the ECB (Punkline's follows the bottom point), and aligns itself a fixed distance from the direct side of the character. It uses camera mode 9 in debug mode. (Note that I'm counting the camera modes starting from 0, so this mode shows as 8 when looking at the camera mode switch in ram (0x80390cfc).)

Example:


For MCM:
-==-


Camera Follows ECB (CM9.3)
Camera aligns itself to the exact side of P1, using the centerpoint of the ECB for tracking. (ECB = Environment Collision Box)

Must switch camera to mode 9 (free roam mode) while in develop mode.
[DRGN]
Version -- DOL Offset ------ Hex to Replace ---------- ASM Code
1.02 ----- 0x80390cfc --- 7C0802A6 -> Branch

3DC08045 81EE3130
820F0110 C1EF0114
C20F07E8 FE2F802A
920E3040 920E304C
D22E3044 D22E3050
3E2042D8 922E3054
7C0802A6 00000000

Spoiler: Gecko

$ Camera Follows ECB (CM9.3) [DRGN]
C2390CFC 00000007
3DC08045 81EE3130
820F0110 C1EF0114
C20F07E8 FE2F802A
920E3040 920E304C
D22E3044 D22E3050
3E2042D8 922E3054
7C0802A6 00000000

Spoiler: source code

$ (uses ECB right's y coordinate for y-axis targeting):

$ Add the leading two bytes of P1's data offset into r14 (actually adds 80450000).
$ Then add r14 to the trailing 2 bytes, go to the resulting memory
$ address, and load the value found into r15.

lis r14, 0x8045 // also is the leading two bytes of CM8's memory addresses (which is static)
lwz r15, 0x3130(r14) // r15 now contains P1's data offset (used to find the character's x & y positions)

$ Add the character's x-coordinate offset to the P1 data offset in r15, then
$ find the value at the resulting address and store it into r16.

lwz r16, 0x0110(r15) // r16 now contains the value found at [P1 data offset + char x-coordinate offset]

$ Add the character's y-coordinate offset to the P1 data offset in r15, then
$ find the value at the resulting address and store it in FPR 15 (for later addition).

lfs f15, 0x0114(r15)

$ Add the character's ECB-Right's y-coordinate offset to the P1 data offset in r15, then
$ find the value at the resulting address and store it in FPR 16 (for later addition).

lfs f16, 0x07E8(r15)

$ Add the character's ECB-Right's y-coordinate (in f16) to the character's TopN y-coordinate (f15)

fadd f17, f15, f16

$ Store the character's x-coordinate into the x-coordinates for CM8's position and TP.

stw r16, 0x3040(r14)
stw r16, 0x304c(r14)

$ Store the result of the FPR addition into the y-coordinates for CM8's position and TP.

stfs f17, 0x3044(r14)
stfs f17, 0x3050(r14)

$ Set CM8's camera position z-coordinate (80453054) to zoom level 108 (42d80000).

lis r17, 0x42d8
stw r17, 0x3054(r14)

$ reinsert the command this injection overwrites
mflr r0

schmooblidon , not sure if this is better for what you wanted or not. To prevent the feet/ground clipping issue due to z-axis perspective, I could do the frame ripping with a code to set the character's z-axis to 0. Some characters might have their feet go below ground anyways due to certain animations, so in the post processing, I could add something to just always clip the character's shape below where the ground would be.

 

[schmooblidon]

schmooblidon , not sure if this is better for what you wanted or not. To prevent the feet/ground clipping issue due to z-axis perspective, I could do the frame ripping with a code to set the character's z-axis to 0. Some character might have their feet go below ground anyways due to certain animations, so in the post processing, I could add something to just always clip the character's shape below where the ground could be.

The center fluctuates, so I can never tell where the base position would be and therefore where to draw the character, perhaps I could find other uses for this though.

Honestly I would not worry about my project anymore, I've found that it takes a lot more work than I expected to add a new character after getting their animations. I don't really want to do any more than 3 characters, and grabbing a chars animations does not take longer than like an hour, which I am more than happy to do. You should focus on you and gentlefox's projects, thank you for offering though

 

[Achilles1515]

Punkline I've done zero research on the subject, but do you happen to know how the camera knows to NOT follow certain characters? Such as Zelda/Sheik that is in sleep, or Nana that has died and is in sleep.

 

[Punkline]

Punkline I've done zero research on the subject, but do you happen to know how the camera knows to NOT follow certain characters? Such as Zelda/Sheik that is in sleep, or Nana that has died and is in sleep.

Afraid not, but looking at the playerThink function that blrls into the camera move logic function pointer stored at internal player data offset 0x21AC shows that both cases of sleeping characters skip the blrl.

Bit 0x10 of the byte at internal player data offset 0x221F seems to be the cause.

From watching the flags at this location, bit 0x10 of 0x221F definitely appears to be involved somehow with the trigger that causes the camera to begin completely ignoring a dead Nana's location (a few seconds after death)

Flagging it manually seems to cause the player to disappear, and has the same effect on the camera that just 0ing out the move logic pointer does. It doesn't stop the camera from tracking the last known position of the player, but halts all further tracking.

I'm not sure what causes the camera to completely ignore a player, but maybe you could find some clues around this flag and its neighbors--which seem to be used in the sleep action state functions:

Spoiler: Sleep flags

 

[Achilles1515]

Aha!

Disable Camera Tracking
li r4,1
lwz r3,0x890(r31)
stw r4,0x8(r3)

(ex. @ 800bfd68 - putting Zelda/Sheik to sleep and disabling camera tracking)

 

[Punkline]

Aha!

Disable Camera Tracking
li r4,1
lwz r3,0x890(r31)
stw r4,0x8(r3)

(ex. @ 800bfd68 - putting Zelda/Sheik to sleep and disabling camera tracking)

Nice work! Just tried it out and can confirm this. Good stuff to know about.

You ever seen that pointer used for anything else? I've never noticed it, and it's directly underneath the action state frame counter...

 

[Achilles1515]

Nice work! Just tried it out and can confirm this. Good stuff to know about.

You ever seen that pointer used for anything else? I've never noticed it, and it's directly underneath the action state frame counter...

Well I had it labeled as "?? Pause Camera pointer data. Loaded at 86bb4, used for shadow system as well"

But I don't really remember writing those notes, so I can't expand upon it with more detail.