Skip to content

[WIP] GeographyObjMgr - MapObj Classes - #49

Draft
MB60893 wants to merge 88 commits into
doldecomp:mainfrom
MB60893:GeoObjMgr-Templates
Draft

MB60893 wants to merge 88 commits into
doldecomp:mainfrom
MB60893:GeoObjMgr-Templates

Conversation

@MB60893

@MB60893 MB60893 commented Jul 23, 2026 •

Copy link
Copy Markdown
Contributor

Note

Keeping this as a draft (work in progress) for now, as there are many classes associated with GeographyObjMgr that could be added to make this a complete PR.

Additionally, some fixes need to be made where there are register mismatches or functions that remain difficult to decompile. See comments in second paragraph below.

GeographyObjMgr - MapObj Classes

This PR contains many classes associated with the GeographyObjMgr class. These classes are typically prefixed by "MapObj" or "TMapObj" followed by the name of the object associated with the courses' geometry.

The majority of the code in this PR is ready to merge, with a few missing functions for ones I couldn't match, or that have minor issues such as register mismatches. These can be found by searching through the commits for this exact string: // FIX: , which will show all the places that are problematic.

Additionally, I'm still not totally across how to fully match the various .data, .bss, .rodata (etc...) segments to get a complete match. That's on me for being new to this. Regardless, I'll keep churning out the functions and I can revisit things later with some assistance.

MB60893 added 30 commits May 22, 2026 17:40
…s that exist as part of the `GeographyObjMgr`.

Something useful is that each of these functions contains the size that the respective class it calls should be, meaning we can determine if the classes being called are missing members. Nice!
…apObjDonkyRock::start()` has a `JUT_ASSERT` specifically referencing this property with the name `mPathID`. Renaming existing implementations to match this.
Note there are a few minor register mismatches, but the majority of the code is a match.
Note one isssue around `mAnmCtrl->ChangeTransAnm(0);` - where it looks like this function may cause some register mismatches.
These were previously decompiled by Sware, so only the import and object creation is present in this commit.
…e that these are inlines used by Coord3DUtil, so it shouldn't impact overall match.
This is a complete match for the class, excluding the last part of `TFreeFallShakeSky::reflect()` where there is a register mismatch.
This includes classes `TMapObjSkyShip`, `TMapObjPathYoshiHeli`, `TMapObjMashBalloon` and `TMapObjUFO`.
There is only one minor  mismatch with `TMapObjUFO::initFunc_Wait()`.
…uired by MapObjGeyser to pass onto `TMapObjHioNode` and, subsequently, `GeographyObj`.
A few function offsets are wrong, but each function matches otherwise.
…elated to creatures in the geography of maps.
Note that `TMapObjSnowRock::hitCheck()` has a register mismatch, probably due to a temporary TVec3f, which I wasn't able to solve.
There are a few things left to do with this class; specifically I gave up trying to get `TTestString::drawNode` to match, and there is a register mismatch on `TTestStrBarrel::checkItemHitting()`.
Note the two register mismatches in `TMapObjHeyho::hitCheck()` and `TMapObjSubHeyho::doFunc_Recover()`.

The `hitCheck` mismatch looks similar to what I've seen in a few other functions, and I'm guessing it's just down to how the TVec3f methods or overloads are being called; I just can't work out the combination to use.

The `doFunc_Recover` function looks like it uses a slerp/nlerp function; but I couldn't work this one out either - maybe something is missing from the JSystem's TQuat4f implementation?
Note that the only thing wrong with this are some of the weak references to Quaternion-related functions such as the `slerp` functions.
…rdering.

NOTE: Fabricated functions were needed to make things match.
…apObjMoveItemBoxLimit` - fixes class sizes based on GeographyObjMgr.)
… through GeographyObjMgr and subsequently fixed.
… a few minor register mismatches, but the majority of the code is a match.
Note that there are some register mismatches which will be resolved by the next commit relating to a TQuat4f's `setRotate` function. Because this could likely impact multiple functions, I'm making this a separate commit so it's easier to track or revert.
A good place to see the fix for this being applied is the `MapObjFireBar` class. With the previous version there were a number of register mismatches.
Something weird also happens in this class as Sware correctly identified earlier - there's BOTH a `virtual` AND `static` declaration for `getSupervisor()`.

`getSupervisor()` is definitely used statically, as is evident by calls in the `DemoTimeKeeper` class; but this is also confusing, as it shouldn't be possible to have a function with the same name be declared static when the base class has a virtual function of the same name... regardless, things still seem to compile OK, so I'll leave it for now.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant