Camera Flags

[engineer124]

This introduces names and defines for the following camera flags:

interfaceFlags behaviorFlags stateFlags viewFlags

And does the small docs for the functions setting and unsetting these flags.

I'm still debating whether to make interfaceFlags a more "compact" macro i.e. CAM_FLAGS(false, CAM_SHRINKWINVAL_MEDIUM, 0xF, PARA1_FLG_10 | PARA1_FLG_8 | PARA1_FLG_2) for example. Maybe modders can shine insight as to what's easier to work with.

Also, because it contains function-unique flags, maybe funcFlags instead of just interfaceFlags

behaviorFlags is also another flag name I'm not quite sure of.

Also, for setting and unsetting flags, I wasn't sure about plurality i.e. Camera_SetStateFlags vs Camera_SetStateFlag

[engineer124]

Cleaned up this PR based on previous discord discussions. Mainly introducing camera-specific interface alpha enums

[engineer124]

For Demo6: There's only one value in data, and its unused. I made the assumption that this one unused value is interfaceFlags because every single set of data seems to have interfaceFlags associated with it. There are a few functions that only have one set of "data" in it, and it's always interfaceFlags

For the cam data macro, I'm not sure about changing it to interface because there's still the issue that only half the flag is interface. The lower two nibbles have nothing to do with interface. sCameraInterfaceFlags is fine because that specifically extracts the upper two nibbles, but I'm still not entirely sure how to resolve this without resorting to the generic flags

For Norm1 vs Normal1, that hasn't been resolved yet. As you mentioned, it's inconsistent. And I'm not sure that's something to address in this PR? This can continue in discord though

[engineer124]

CAM_FUNCDATA_SUBJ4

I'll take a second look at this data in the upcoming crawlspaces (Subj4) PR

[Dragorn421]

(mostly copypasted from Discord)

The behavior/state/view camera flags exhibited in this PR are "real" flags (each bit being set/clear is a separate piece of information)

But according to recent discussion (on the sfxparams PR) the "interface flags" wouldn't be "flags" as they don't fit that definition:

#define CAM_INTERFACE_FLAGS(shrinkWindowFlag, interfaceAlpha, funcFlags) (see z64camera.h)

Note: it's unclear what to call this "interface flags" data at all, "interface" only fits the shrinkwin/interfacealpha data but no one has had an idea for a better name yet

shrinkWindowFlag

shrinkWindowFlag can be:

• CAM_SHRINKWINVAL_[size]
• CAM_SHRINKWINVAL_[size] | CAM_SHRINKWIN_INSTANT (switch instantly instead of progressively)
• CAM_SHRINKWINVAL_IGNORE (retain previous value)

Comparison by engineer of the CAM_SHRINKWINVAL_none/small/medium/large values: (small is unused in both OoT and MM)

These values may be better as 0/1/2/3 maybe instead of defines/enums, cf engineer's following comment (copied from Discord):

It has the same bit-packed "small/medium/large" -> "1, 2, 3" values that's very comparable to the SFX_PARAMS -> SFX_DEFINE arguments for both "decaying volume" and "random freq noise", that's left as just a (1, 2, 3) instead of actually putting the SMALL/MEDIUM/LARGE enums: https://github.com/zeldaret/oot/pull/1296/files

So I'm thinking we should figure out a style that comes with "small/medium/large" values and whether we should have enums or leave it as numbers

interfaceAlpha

interfaceAlpha can be

• CAM_HUD_ALPHA_50
• CAM_HUD_ALPHA_1..CAM_HUD_ALPHA_D (1-13)
• CAM_HUD_ALPHA_IGNORE

This will be revisited eventually

funcFlags

funcFlags is a bunch of flags specific to a camera function, for example NORMAL1_FLAG_1 | NORMAL1_FLAG_0 (see CAM_INTERFACE_FLAGS usage in z_camera_data.c)

[engineer124]

Updated names to sync with "Letterbox" and "Hud Visibility"

[Dragorn421]

Note: this now only needs a contributor approval for merging, but Roman expressed concerns about calling things like the bit-packed CAM_INTERFACE_FLAGS "flags"

EDIT: if you want to weigh in, I described what's going on in a comment above https://github.com/zeldaret/oot/pull/1225#issuecomment-1173153276

[engineer124]

The latest Hud Visibility Mode Docs have now been incorporated into this PR

[Dragorn421]

Status update on this PR:

The "Needs discussion" label refers to the interfaceFlags name, which isn't really purely "flags". And the "Needs lead approval" is still there despite two lead approvals, as Roman expressed the will to review this before merging

---

Since the "flags" name is already there in master, I would personally consider renaming it to be out of scope or at least not required to change in this PR, but I feel like that's subjective so I'll leave the "Needs discussion" label up. Afaik only Roman has taken issue with it being named "flags"

[engineer124]

On the topic of the name "interface flags", I don't have a good suggestion either, unfortunately, but I'd say we should at least move to "params" or "field" since "flags" is arguably just wrong

field would work for me. params is already used in "paramsData", although the data in question is saved as a struct member to "paramsData". I don't even know if "shrink window" should be attributed to interface, and I know the function-specific cam-flags definitely aren't. So it's kinda forced to be more general. @Dragorn421 had an idea of sCameraPropsField and maybe each member of the ReadOnlyData subset of paramsData can have it's struct named propsField?

[fig02]

personally not the biggest fan of "propsField". feel like you should just pick one, properties or field

and yeah the issue between properties and literal prop I dont like personally. I dont think movie prop makes sense in this context, but could be misunderstanding what this does

[engineer124]

personally not the biggest fan of "propsField". feel like you should just pick one, properties or field

It's now been set to interfaceField for now

[fig02]

(i approved based off of a high level review, didnt get into the details. id still wait for romans approval for merge)