Quote:Original post by RandomCode
I don't remember where I read that, but it made sense to me. Because I want the the camera to follow the player at all times. Moving the camera and the player would mean extra calculations I guess :S
What extra calculations would that require? Can you give an example?
Assuming a standard pipeline (such as that of OpenGL or DirectX), what gets moved, and how, is a conceptual rather than a practical issue. In the end, the geometry is pushed through a pipeline that consists of, among other things, a series of transforms. The transforms are always of the same number and type (AFAIK, at least) regardless of how you set things up on the client side.
In OpenGL, for example, prior to the projection stage all geometry is processed uniformly by the 'modelview' transform. This transform transforms geometry from its own local space into camera space. Whether you think of the world as moving around the camera or the camera as moving in the world is once again purely conceptual; it has no practical bearing on the performance of your application, or on the visual output.
As such, IMO it's best to manage transforms in the way that makes the most intuitive sense, and is most practical from an implementation standpoint. If as far as your simulation is concerned the player is moving in a world that is static, then move the player and let the world be stationary. If the camera is intended to follow the player, then have the camera follow the player. Assuming you manage your transforms correctly (combine them in the right order, invert the camera transform as appropriate, and so on), everything else should take care of itself.