Page 1 of 1
Screen Shaking itself to oblivion
Posted: Tue Oct 14, 2008 5:44 pm
by 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?
Posted: Tue Oct 14, 2008 5:52 pm
by bert_the_turtle
Can you post your computer's specs? The shaking you describe sounds like the one caused by low FPS.
Posted: Tue Oct 14, 2008 8:05 pm
by the4ce
I have this problem to if the map contains to many multiwinians/ants...I think its from my computer.
Posted: Wed Oct 15, 2008 2:07 am
by elexis
Does it happen with the latest patch?
Posted: Thu Oct 16, 2008 3:55 pm
by frenchfrog
Update your video drivers and turn down graphical settings/resolution?
Posted: Fri Oct 17, 2008 11:49 am
by 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

Posted: Sat Oct 18, 2008 8:51 pm
by DoubleFelix
The camera system needs fixing...
Posted: Sat Oct 18, 2008 10:28 pm
by 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?
Posted: Sun Oct 19, 2008 5:08 am
by DoubleFelix
RabidZombie wrote: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.
Posted: Sun Oct 19, 2008 6:42 am
by 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.
Posted: Sun Oct 19, 2008 9:09 am
by 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?
Posted: Sun Oct 19, 2008 1:04 pm
by 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...
Posted: Sun Oct 19, 2008 2:12 pm
by bert_the_turtle
cde wrote: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 camDirThis 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.
Posted: Sun Oct 19, 2008 3:16 pm
by cde
Excellent breakdown of possible cause/solution there - if that's all it is, let's hope 1.1.1 has smoooooth cameras!
Posted: Sun Oct 19, 2008 3:20 pm
by frenchfrog
Nice one
