I want to make a camera shake effect when a scary monster comes chasing after you or at least for a cinematic effect then the player can do whatever.

if (isKeyPressed(0x56))  //-- If V key is pressed.
		{
			static float shakeAmount = cameraYaw;
			static float maxShake = cameraYaw + 1.0f * (XM_PI / 4.0);
			static float rndJerkiness = ((rand() % 2) - 4);

			shakeAmount += cameraYaw + rndJerkiness; // ((rand() % 2) + cameraYaw - 2); // +(XM_PI / 4.0f);

			if (shakeAmount > 1.0f  * maxShake) {
				shakeAmount -= rndJerkiness;
			}
			if(shakeAmount < -1.0f * maxShake) {
				shakeAmount += rndJerkiness;
			}
			cameraYaw *= shakeAmount;
			std::ofstream out("Logs/Camera.log", std::ios_base::app);
			out << cameraYaw << ":" << cameraPitch << std::endl;
			out.close();
			//shakeAmount = 0.0f;

		}

As of now it's just tied to the V key for testing purposes. The camera yaw is tied to the updateCamera function which is tied into the pitch, roll and yaw function of the xnamath.h header file.

I'm getting close the camera shakes alright - sometimes it gets out of control and the screen turns black inside the level editor. Possibly something happened and it went past the sky box which is literally impossible because the skybox is scaled for infinity. I'm not sure what's causing that anyways. The random jerkiness is to make it appear jerkier and spazmatic. I was trying to make it random from - 2 to 2. It's outputted for now so I know what's going on inside the log file. The cameraYaw is initialized as 0.0.

I was just wondering if there was something I can do better inside the code?

a simple screenshake that uses Haegarr's random interval (-2 though 2), and changes position, not rotation (a la Ankhd's method)...

 
setcam( player_x+dice(5)-2, player_y+dice(5)-2, player_z+dice(5)-2 );
 

this is the type of approach i usually use

the same idea in a rotation:

 
setcam (player_x, player_y, player_z, player_xr+dice(21)*0.01f-0.1f, player_yr+dice(21)*0.01f-0.1f );
 

this aims the camera in the player's direction, with a "jitter" of -0.1 to 0.1 radians in x and y rotations.

in general, i've found that it doesn't require much jitter to get the desired effect. just move the camera a foot or two, or just a couple of degrees.

Only reason why I chose the rotation not position is because the rotation avoids collision detection with walls - so if the player is pinned against the wall and the camera shake happens - then there could be issues, right? In some games I was able to go pass the physics collider of a wall or something with enough running and jumping at the wall (doesn't do it a lot though). The rotation keeps the player at the same position giving a bit jitter.

so if the player is pinned against the wall and the camera shake happens - then there could be issues, right?

yes, that could lead to clipping issues and graphic artifacts (IE camera behind wall for a moment). but it would seem to me that a wall would get backface culled when the camera popped behind it for a moment, so it would probably still look ok.

either type of jitter (position or rotation) ought to work ok, with only minor differences in camera behavior (how it shakes).

excessive and cumulative jitter is what caused your initial problems.

In some games I was able to go pass the physics collider of a wall or something with enough running and jumping at the wall

their stepped movement interval is too large, or they're not using stepped movement at all, or their collision detection range is out of sync with their movement step size.

when jittering, you only move the camera, not the player. in fact, i often implement it not as a continuous realtime effect during gameplay, but as a quick canned animation, draw about half a second's worth of frames with jitter, then continue. works great for things like taking hits with your shields down. an example of continuous would be the gravcar "float" in Combat Racer, a simple:

 
current_y = base_y + sin(turn_counter)
 

before you draw each frame. it makes the gravcars float up and down over time.

Yes, the execessive jitter was the main issue because I looked at the log file and I saw the if statements were never being reached because the cameraShakeAmount was constantly accumulating to the current camera Yaw and testing to see if if was greater than the maxium shake amount was never being reached. So I came up with this new code which helps out a lot more than previous and I don't have to multiply the results to the camera yaw - just assign it.

void CameraShake() {
		static float shakeAmount = 0.0f;
		float oldCameraYaw = cameraYaw;

		static float maxShake = 1.0f * cameraYaw + (1.0f * XM_PI / 2 * 0.2f);
		static float rndJerkiness = ((rand() % 5) - 2);

		shakeAmount += 0.5f; // +rndJerkiness; // ((rand() % 2) + cameraYaw - 2); // +(XM_PI / 4.0f);

		if (shakeAmount > 1.0f * maxShake) {
			shakeAmount *= -0.5f; // * rndJerkiness;
		}
		if (shakeAmount < -1.0f * maxShake) {
			shakeAmount *= 0.5f;// *rndJerkiness;
		}
		oldCameraYaw = shakeAmount;
		cameraYaw = oldCameraYaw;
		updateCameraLens();


	}

I know I can use XM_PIDIV2 for the max shake equation but I'll get to that later. What's good is that it doesn't shake out of countrol leaving the player facing the other direction. If the player got to ecape he sure doesn't want to face a wall or obstacle each time the ground shakes. The camera shake may be used as a post process effect which I'll get into later because I don't think I want the camera to shake all the time - only when there's a major event happen to signify the importance of why the ground is shaking. Like tomb stones rising from the ground or something or the ground breaking in half causing the camera shake effect to happen. Or when the house explodes at the ending or something like that.

I may even create a joint for the camera to the player so if the ground shakes the camera will be linked to the player already as the player moves up and down - creating the effect of camera shake in first player mode.

I love the fact when I come on here my creative juices begin flowing because of the help with great people on this forum.