GoldenEye 007 Nintendo 64 Community, GoldenEye X, Nintendo 64 Games Discussion

[stolen]

For the past few hours I've been dumping data and arranging it into a excel document. I'm having some issues trying to understand as to why strafe running results in a giant speed boost which shifts you off center. Would anyone know as to why this is happening?

Last edited by stolen on Sun May 05, 2013 9:12 pm; edited 1 time in total

[zoinkity]

Incremental speed.
Sidestepping and normal movement are registered as two different effects. The two are effectively additive; they didn't bother compensating for this. The effective movement cap is the 'falling' rate, with the exception of vehicles. Vehicle movement and controls are managed entirely differently.

Incidentally, depending on the controller (on console) or the way the emulator is set up 'maximum' on the control stick could be any range of values.
_________________
(\_/) Beware
(O.o) ze
(> <) Hoppentruppen!

[stolen]

zoinkity wrote:

Incidentally, depending on the controller (on console) or the way the emulator is set up 'maximum' on the control stick could be any range of values.

I had the controller set up as 1.2, and only used C-buttons. I hope this is a consistent way of extracting data.

I have understood a few formulas, but I still don't understand as to why there is such a large jump for strafe running, which then makes you run off-center.

[zoinkity]

The camera is not 'fixed' to the body as in modern titles. The two are entirely independant and even use different sets of position data (note the plural). Although 'character' and 'vehicle' movement are handled differently, there is only one handler for the camera.
There are a few things that act specificly on one or the other, and a few that 'correct' both in different ways. Each has its own momentum counters and they are not identical.

The body position only sets the base centerpoint coordinates for the model. Depending on the current animation, you may be drifting in any particular direction or appear completely offset from this position. Death animations are particularlly bad about this.

Interestingly, the camera is not aligned behind your character. For example, bodies are forced directly down to the ground by default. The camera, however, is set at a dictated position from the centerpoint of the character. As a test, aim a pistol directly at the head of a character from your screen's perspective and check how that looks to the player being pointed at and an outside observer. The position is usually higher and set forward of the actual body position.
The camera will also trace using its momentum and follow vertical movement properly, even when a body is automatically forced to the ground. To a degree the same thing happens while moving laterally. Bodies don't really slow down or speed up beyond controller feedback. The camera, though, has a momentum system and a maximum increment/decrement to 'smooth' your motion.

The most noticable difference is how deaths are handled. Even though both the body and camera are being moved by the same code, the actual visible result on your screen versus the perspective outside will seem very different. Same exact motion in this case, with different results. The offseting is key in this case, since the imaginary post the camera is set on is moved exactly like the independant head despite the two are in different positions and, incidentally, have a different origin (heads are moved relative to their necks, moved relative to the joint against the body, though the camera is on a fixed post).

The sine wave used for 'player gait' is handled differently by the body and camera. It corrects the body position forward and back in a somewhat unrealistic fashion. If you were to increase it, the character will appear to jump forward a step and back a step as they move linearly. If | is where they're really at and _ where they appear, it would look like this:

Code:

|,  _|, |, |_, |

The camera follows a more complicated path since gait acts as a multiplier against ordinary 'wiggle'. This is multiplied, in turn, against the values for the current equipment which can, in fact, completely remove the feature.

Finally, the camera is autofixed when it is too wrong. I should say, the camera automatically enters a different mode when it strays beyond a certain distance from the body, switching from 1st person to 3rd person. The default behaviour at that point is the 'return to 1st person' triggered during the intro cameras.

As mentioned before, strafing uses a different speed increment which is added directly to any other motion. This is why diagonal running is inherently faster. Add this to the various different position modifiers and compensate for how the camera needs to rate-adjust to keep up and you've pretty well explained away the behaviour. What you're noticing is how two independant systems both react to the same kind of data.
_________________
(\_/) Beware
(O.o) ze
(> <) Hoppentruppen!

[stolen]

Thank you for explaining the camera/movement system. I first suspected the camera and body were different systems when I found 2 sets of position data, but I was unaware as to how complex these systems really are.

When you said "This is multiplied, in turn, against the values for the current equipment which can, in fact, completely remove the feature", what did you mean by 'current equipment'?

[zoinkity]

Current equipment would be whatever weapon or item you have out currently. It can effect the sway, which in turn amplifies the rest of the camera inaccuracies. It's more a correction than anything, unlike PD's system that allows you to completely alter all movement values. In that resepect it works more like the vehicle system in GE.

Incidentally, I've counted at least six sets of 'current positions' actively used for any single player in game. There's probably more. It is absolutely stunning the amount of redundant data in this game, though the absolute worst about it was Mario Kart 64. I pity anyone seriously attempting to hack that game.

NSNA tried to straighten a bit of it out. Managed to use height mods to set the camera height, so at least it floats just above their heads. It also got around a bit of the obsessive double-copying stuff.
_________________
(\_/) Beware
(O.o) ze
(> <) Hoppentruppen!