Skip to content

Conversation

@tropicsquirrel
Copy link

Updates cursor mode to the camera pans similarly to realMyst or Myst V.

{
// rotate the camera in accordance with how close the cursor is to the edge of the screen
this->AddPitchInput(
VerticalMouseNudgeThreshold - (1 - VerticalMousePosition));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not certain this is the right expression. We would want the amount nudged to be proportional to how much of the threshold has been moved across. If the cursor has barely impinged into the threshold, let's say 1% of the threshold, then this pitch input argument would be VerticalMouseNudgeThreshold * 99%. If the cursor has impinged a lot (50%), the number would be less, VerticalMouseNudgeThreshold * 50%. Does that sound right? Either way, some more explicit variable names would make things a bit clearer. For instance

auto farImpingement = FMath::Clamp(1 - VerticalMousePosition, 0.0f, 1.0f);
auto nearImpingement = FMath::Clamp(VerticalMousePosition, 0.0f, 1.0f);

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in testing the current code appears to do just that - if the cursor is closer to the edge, the camera moves faster. if nearer to the center, it moves slower.
intent was to avoid making more variables/function calls than necessary.
may be more of a style thing. happy to use clamp instead if desired.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, I think I ironed out why this is weird to me: the bigger the threshold is, the more the maximum camera spin velocity will be. Basically you have v = t - y where v is velocity, t is threshold size, and y is measured coordinate. The maximum velocity will be y = 0, so v = t - 0 = t. So v is proportional to t. What seems more natural to me would be v = (displacement of cursor into threshold region) / (size of threshold region). In other words, for the top region, that'd be v = y / t and so on.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i see what you're saying. it's a bit counter-intuitive but knowing that the screen space in this function is measured from -1.0 to 1.0 it seemed to be the method that required the fewest calculations and function calls. also, the commit last night allows for a multiplier so you can have a really small threshold and a really fast (or slow) turn rate.

@philip-peterson
Copy link
Member

Let's also revert the commit with the file mode changes (as I'm guessing that was accidental), unless there's a reason not to.

@cmumford
Copy link
Member

looks ok. you may want to run fix-formatting.sh before landing.

…rsor nudges the camera near the edge of the screen."

This reverts commit f4ea2f7.
-updated comments and formatting in accordance with team style
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.

4 participants