The current built-in system is decent for some cases, but, when huge levels are involved (exceeding 60,000 quants in diameter), it can take several minutes to get to the other side of the level. Then, the fast motion from the sudden acceleration makes it tricky to get the camera in a certain spot. The best solution is to utilize acceleration. At first, the camera starts off slowly, allowing for fine movement. If the up arrow key is held for extended time, the camera keeps on accelerating thus being able to get 500,000 quants from the level's origin in only about a minute or so. Then, from here, one could fine-tune their positioning from this far out. All that's needed is a behavior like this:

Code:

---

function accel_camera()
{
	var horiz_speed[2] = 0, 0; // old then new speeds
	var vertic_speed[2] = 0, 0; // old then new speeds for vertical movement
	var cam_dist = 0; // camera distance
	
	while(1)
	{
		// First, we'll establish the camera angle.
		if ((key_cul == on) || (key_cur == on)) // if turning the camera
		{
			if ((key_cul == on) && (key_cur == off)) // left is positive in Euler angles
			{
				camera.pan += 5.625*time;
			}
			
			if ((key_cul == off) && (key_cur == on)) // right is negative in Euler angles
			{
				camera.pan -= 5.625*time; // turns 16*11.25 or 180 degrees per second
			}
			
			if (camera.pan < 0)
			{
				camera.pan += 3600; // make positive
			}
			
			camera.pan %= 360; // keep within range of 0 to 360
		}
		
		if ((key_pgup == on) || (key_pgdn == on)) // if tilting the camera
		{
			if ((key_pgup == on) && (key_pgdn == off)) // pitching upwards
			{
				camera.tilt += 5.625*time; // tilt the camera upwards
			}
			
			if ((key_pgup == off) && (key_pgdn == on)) // pitching downwards
			{
				camera.tilt -= 5.625*time; // tilt the camera downwards
			}
			
			camera.tilt = clamp(camera.tilt, -90, 90); // can't tilt camera beyond straight down and straight up
		}
		
		// Next, we'll move the camera based on that angle
		if ((key_cuu == on) || (key_cud == on)) // if moving
		{
			horiz_speed[0] = horiz_speed[1]; // record previous speed
			horiz_speed[1] += (3.667*time); // update current speed for acceleration
			cam_dist = (horiz_speed[0] + horiz_speed[1])/2*time; // average speed and find distance to travel
			
			if ((key_cuu == on) && (key_cud == off)) // one key can be pressed - up is forward
			{
			   camera.x += cos(camera.pan)*cam_dist*cos(camera.tilt); // move camera accordingly
			   camera.y += sin(camera.pan)*cam_dist*cos(camera.tilt);
			   camera.z += sin(camera.tilt)*cam_dist; // if going up, move the camera up
			}
			
			if ((key_cuu == off) && (key_cud == on)) // one key can be pressed - down is backward
			{
			   camera.x -= cos(camera.pan)*cam_dist*cos(camera.tilt); // move camera accordingly
			   camera.y -= sin(camera.pan)*cam_dist*cos(camera.tilt);
			   camera.z -= sin(camera.tilt)*cam_dist; // backwards is the reverse
			}
		}
		
		if ((key_cuu == off) && (key_cud == off)) // reset speed if no position-changing key is used
		{
			horiz_speed[0] = 0;
			horiz_speed[1] = 0;
			cam_dist = 0;
		}
		
		wait(1);
	}
}

---

This makes it easier for getting around huge levels and fine-tuning positioning. The rotations, however, need some adjustments though. With this small piece of code, you could get around huge levels easily and quickly and you can fine-tune the positioning more easily as well. I think walk-through mode should use something similar. Currently, it's a slow 20 mph constant speed (8 quants to 1 foot map scale) or 40 mph if the shift keys are held, too slow for huge levels. With this, topping 3000 mph is easy which is why it helps. Could, in some future update, Gamestudio have this similar behavior built-in?

Edit: 3.667 is 80 mph per second per second acceleration where your map scale is 8 quants to 1 foot

Currently, you can accelerate camera movement by
hold down SHIFT + cursor keys/home/end/PageUp/PageDn...etc.

or try my small program : jump to hot spot

By holding the shift keys, the speed is doubled, but even with that, getting all the way out to 100,000 quants from the origin will take almost 4 minutes to do with that (8 minutes otherwise). Using my system as depicted above would make it possible in about 20 seconds, if that. It's user-friendly as well and is easy to use.

just enter your desired position... takes 3 seconds, if you're fast.

It's not always straight forward to doing that. Plus, watching your level whizzing by at twice the speed of sound can be fun as well. When you need to see something up close, the sudden fast movement can make it tricky to get that close-up. With acceleration used, it solves both issues.

Why don't you just set shift_sense to something greater than 2 (default) ?
Setting it at 10, for example, will make things quite a lot faster

Even on the slow speed, there's a sudden burst of speed and it can still be tricky to position the camera properly without having to press forward, then backward and forward, and so on until you get into that one position. With acceleration, this solves this issue. Why would getting fine-precision positioning be needed? I've had a cases where a strange highlight was present in the way a textured object looked. It was because it wasn't tiling properly. With such a fine texture scale used, I had to get very close (camera.clip_near = 2 at the point of which it was clipping away was barely close enough) in order to see why it was happening. I don't recall how long it took, but it's around 30 or 40 seconds. With acceleration, I could make the fine adjustments with ease and this task would've otherwise only taken about 2 or 3 seconds instead at the most (with better positioning precision as well to get a further enhanced look at it). It's impossible with the built-in camera movement system so I made my own system to work around this and since I've learned some trig, I refined it so I can move the camera in any direction rather than set on one axis only. I also made it possible to cycle through acceleration rates from 5 mph per second to 20 and 80. The script I use uses the 80 system, and is based on a map scale of 8 quants making one foot. It's also a lot more fun watching everything in the level whizzing by at the speed of sound (and beyond that).



This screenshot from 18 months ago gives a good example of why this would come in handy, only with the texture scale at 2x. What's causing those white lines? Only a close-up could tell and with the way the camera's motion is, it's hard to do that. With acceleration, I can ease in much easier and faster. My recent case is where the texture pixels were 9 times finer and I really had to get up close and the odd border wasn't as noticable as this case was meaning a major close up was needed.