Screen Shaking itself to oblivion

[Robo Pope]

Whenever i play Multiwinia on my computer (no not a laptop) in multiplayer mode,about three minutes in the screen starts shaking enormously until it shakes off the map until i only see black and constantly shifting crate and powerup location markers.

anyone know how to fix this?

[bert_the_turtle]

Can you post your computer's specs? The shaking you describe sounds like the one caused by low FPS.

[the4ce]

I have this problem to if the map contains to many multiwinians/ants...I think its from my computer.

[elexis]

Does it happen with the latest patch?

[frenchfrog]

Update your video drivers and turn down graphical settings/resolution?

[cde]

I have also had this on a decent spec system, with all settings at minimum. I think it is a little short-sighted to blame hardware or settings when there is a fairly widely reported issue with the camera movement that can result in this jerking motion.

Good luck finding a solution, it would surely need to be resolved before the XBLA launch

[DoubleFelix]

The camera system needs fixing...

[RabidZombie]

Actually, the problem described here is from low FPS.

cde, if you're having camera problems which aren't related to low FPS, can you start a new thread?

[DoubleFelix]

Actually, the problem described here is from low FPS.

cde, if you're having camera problems which aren't related to low FPS, can you start a new thread?

Every camera issue I've seen has been caused by low FPS, but low FPS is no excuse for the camera to bounce around in a way that would NEVER happen otherwise.

[cde]

To be clear, the machine is decent but when I moved the camera through a tree with lots of action going on, the fps dropped and the problem kicked in. It has also happened during meteor showers - fps drops, camera goes crazy.

I am not sure if other people find this problem fixes itself, but I have found that once it begins it is very hard to move the camera to a "safe" place and calm it down.

My point is that low settings or good specs don't guarantee high fps, so there may be a remaining risk that the XBLA version could get the same bungie-cord-camera if the player looks at the wrong thing.

[Qjet]

I think this says something about how the game performs under load. Isn't this a sign that improvements need to be made somewhere?

[cde]

I suspect there is something simple - but hard to pin down - amiss with the "easing" code that brings a moving camera to a gentle stop. However, every time someone reports something that occurs at low FPS I am more concerned that the response is "drop your settings" rather than "we need to make sure low FPS causes fewer problems".

I have not checked lately to see if this jerking occurs when using the Xbox 360 controller on Windows, though on a more positive note, if you have one lying around, it does have some rather nice analogue control over camera speed...

[bert_the_turtle]

but hard to pin down

Probably not. Problems of this kind usually have one reason: Explicit Euler. The basic Explicit Euler camera direction update code would be something like this:

Code: Select all

// variables:
// dt: timestep (basically 1/FPS)
// camDir: current camera direction (a vector)
// camTargetDir: the direction the user wants the camera to point at, we want to "ease" towards it. Also a vector.
// camSpeed: a float; gives the speed of the camera easing
camDir += ( camTargetDir - camDir ) * camSpeed * dt;
// then, normalize and sanity check camDir

This code is called every frame. What it is trying to do is to numerically solve the differential equation (d/dt)(camDir) = ( camTargetDir - camDir ) * camSpeed, which, if solved exactly, would let camDir smoothly converge towards camTargetDir.
The problem: if camSpeed * dt is bigger than 1, the easing will overshoot the target a bit, and instead of smoothly moving towards it, it will jiggle around. As long as camSpeed * dt < 2, it will still sort of work and converge to camTargetDir eventually. If that's no longer the case, the difference between camTargetDir and camDir will get bigger every frame, causing the observed massive uncontrollable shaking.

The solution: be smarter For example, you can use Implicit Euler. For simple differential equations like this, changing the update code to

Code: Select all

float epsilon = camSpeed * dt;
camDir += ( camTargetDir - camDir ) *epsilon/( 1 + epsilon );

does the trick. For small epsilon, the extra 1/(1+epsilon) factor doesn't do much, but for large epsilon, which were problematic before, the total factor epsilon/(1+epsilon) stays below 1 and never makes camDir overshoot.

[cde]

Excellent breakdown of possible cause/solution there - if that's all it is, let's hope 1.1.1 has smoooooth cameras!

[frenchfrog]

Nice one