matched CameraEngineZoneColl

[Mhanna112-code]

No description provided.

[decomp-dev]

Report for GLLE78 (a4df488 - 1cc600f)

📈 Matched code: 13.79% (+0.00%, +28 bytes)
📈 Linked code: 9.71% (+0.00%, +28 bytes)

✅ 1 new match

Unit	Item	Bytes	Before	After
main/Engine/CameraEngineZoneColl_Z	CameraEngineZone_Z::CameraGameColl(const World_Z*, Vec3f, Vec3f, float)	+28	0.00%	100.00%

[0x5abe]

Thanks for making a PR! Don't worry about the format check failing cause it's complaining about other stuff that isn't what you added.

Looking into it a bit further this seems to be a fake match, since CameraEngineZone_Z doesn't have a position at offset 0x0. You can see that it inherits other classes here:

RatDecomp/docs/inheritance.md

Line 33 in a4df488

CameraEngineZone_Z -> CameraEngine_Z -> Manipulator_Z -> BaseObject_Z

And BaseObject_Z doesn't have a position at 0x0:

RatDecomp/src/Engine/includes/BaseObject_Z.h

Line 12 in a4df488

Name_Z m_Name;

The issue here is that the compiler most GC games used (MWCC) likes to use the r3 register (which is normally the this pointer) as an output parameter pointer when a function returns a struct bigger than 4 bytes. In this case the function isn't void, in reality it returns a Vec3f, that's why r3 ends up being a Vec3f*, which in turn leaves the this pointer to be placed in r4, and so on with the other parameters. (See Storage in the image below)

---

In terms of the style of the code, we have a document which defines the styling expected: https://github.com/ZounaModding/RatDecomp/blob/main/docs/styling.md.

To fix it in this case you won't have to worry about the position member in CameraEngineZone_Z since it's not real, so you can remove it. Maybe add the inheritance hierarchy if you want. What you should update is the signature of CameraGameColl to use the proper naming style for input variables.

I also realize that we don't have any document explaining anything about our typedefs, but we have this file: https://github.com/ZounaModding/RatDecomp/blob/main/src/Engine/includes/Types_Z.h where we define the types that should be used (most of the time). In this case instead of float you would use Float.

With all of that put together, the changes needed to merge the PR would be:

• Remove the position member from CameraEngineZone_Z
• If you want to, define CameraEngine_Z, which inherits Manipulator_Z, and make CameraEngineZone_Z inherit from it
• Update the signature of the function to match the one below, and match the body accordingly

Vec3f CameraGameColl(const World_Z* i_World, Vec3f i_CamPos, Vec3f i_CamTarget, Float i_DeltaTime);

I figured out the parameter names with Ghidra, looking at the context, if you want us to add you to the Ghidra shared repository ping @/sabe. (me) or @/z.berg in the Zouna Underground discord server.

Sorry for so many points brought up considering it's a small function. It's just the fact that the project is really in its infancy, and we don't have any proper onboarding on how to contribute. As well as a lot of stuff not being defined at all (like how you had to make the class for CameraEngineZone_Z). Feel free to ask any questions here or in the discord!

[Mhanna112-code]

all fixed up

[0x5abe]

Thanks for fixing it up!

The build fails because the signature of CameraGameColl has a World_Z* instead of const World_Z*, so when linking multiple files together it fails to find it.

I'll merge it so I can fix this, and also make some small style fixes, then I'll send the link of that commit to you so you can see what I changed for future PRs that you make.