
function move_camera() // declare the function without parameters
{
/* These are local variables, present only in the function and temporary. They
are slower than global variables, but do have uses. */
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
/* The "[2]" means an array of length 2, or two variables under the same name. In
this case, the old and new speeds are being logged. */
while(1) // a loop without end
{
// First, we'll establish the camera angle.
if ((key_cul == on) || (key_cur == on)) // if turning the camera
{
/* This is only processed if the condition is true, holding the left arrow
key or the right arrow key. */
if ((key_cul == on) && (key_cur == off)) // left is positive in Euler angles
{
camera.pan += 5.625*time;
/* Camera rotates left if the left arrow key is pressed, but not the
right arrow key. If so, it should rotate 5.625 degrees per tick. A tick
is 1/16 of a second thus a rotation of 90° per second. Time is the
duration of the last game frame, in ticks. From the forums, I know that C
uses radians rather than degrees so I'll need to do that conversion as
well - 180/pi to get degrees from radians. */
}
if ((key_cul == off) && (key_cur == on)) // right is negative in Euler angles
{
camera.pan -= 5.625*time; // same here as above, only for turning right
}
if (camera.pan < 0)
{
camera.pan += 3600; // make positive
}
camera.pan %= 360; // keep within range of 0 to 360
/* The first part is used to get a positive value. If a variable was -3 and
I used variable%=10; in C-script, I'd get 7. Someone on the Gamestudio
forums said that you'd get 3 instead of 7. %= gives the remainder of a
division (modulo function) and thus 3 would seem correct. */
}
if ((key_pgup == on) || (key_pgdn == on)) // if tilting the camera
{
/* key_pgup refers to the page up key and key_pgdn refers to the page down
key. This is otherwise the same as that of the pan, only with the tilt, up
and down movement rather than left and right. */
if ((key_pgup == on) && (key_pgdn == off)) // pitching upwards
{
camera.tilt += 2.8125*time; // tilt the camera downwards
/* Pitch up at 45° per second, half as fast. */
}
if ((key_pgup == off) && (key_pgdn == on)) // pitching downwards
{
camera.tilt -= 2.8125*time; // tilt the camera upwards
}
camera.tilt = clamp(camera.tilt, -90, 90);
/* This prevents the camera's tilt from going any more "down" than straight
and going any more "up" than 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] += (cam_accel[1]*time); // update current speed
cam_dist = (horiz_speed[0] + horiz_speed[1])/2*time; // average the speed
/* What this does is it uses the distance-acceleration formula (as I call
it) which determines how fast the camera should move. It adds the
acceleration rate (the "cam_accel[1]" variable) to the speed then computes
the average speed, the distance to move. */
if ((key_cuu == on) && (key_cud == off)) // one key can be pressed - forward
{
camera.x += cos(camera.pan)*cam_dist*cos(camera.tilt); // move camera
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 - backward
{
camera.x -= cos(camera.pan)*cam_dist*cos(camera.tilt); // move camera
camera.y -= sin(camera.pan)*cam_dist*cos(camera.tilt);
camera.z -= sin(camera.tilt)*cam_dist; // backwards is the reverse
}
/* Pressing the up arrow key moves you forward and the down arrow key moves
you backwards in whatever direction you're moving in. This allows for
movement on all 3 axes at once. Now, if falling a few hundred mph wanting to
go, say, northeast, movement would be nice, wouldn't you think? */
}
if ((key_cuu == off) && (key_cud == off)) // reset speed if not travelling
{
horiz_speed[0] = 0;
horiz_speed[1] = 0;
cam_dist = 0;
}
/* If this is left out, the speed I leave off on would be the same I start with
when I begin to move the camera around again. This would eventually cause the
camera to initially move so fast, control would be very hard and eventually
become impossible to control. This prevents that from happening, starting from
a complete stop. It fixes a potential bug. */
wait(1);
/* This causes the loop to wait one frame before being executed again. As far
as I know, this is a Gamestudio-only feature. If regular C doesn't have it,
then I'd likely need to make such a system, but don't know how. */
}
}
| Feature | IA* | CRT details | LCD details |
| Max resolution | 2.1 | CRT monitors have a higher maximum resolution than an LCD monitor does for the same viewing angle. CRT's can go clear up to 2048x1536. | LCD monitors have a bit lower maximum resolution. I have yet to see an LCD supporting above 1600x1200 as the maximum resolution. |
| Resolution support | 1.8 | CRT monitors support any resolution, low and high, very well with no loss in quality. This is a great feature for gaming and game development. | LCD monitors, however, only support one native resolution. There is a big drop in quality when such a monitor uses a different resolution. |
| Clarity | -1.3 | CRT monitors are a little less clear than that of an LCD due to a lower contrast ratio. | LCD monitors have a higher contrast ratio and this helps with clarity. |
| Colors allowed | 1.5 | CRT monitors support the full 16 7/9 million colors. When doing artwork or game development where high-precision color determination is needed, this is otherwise a requirement. | From what I know, LCD monitors don't support the full 16 7/9 million colors, but rather that of 18-bit (from what I read on the Gamestudio forums). That's only 262,144 colors. |
| Price | 7.2 | CRT monitors have a base price 1/3 that of the LCD. Even with the hefty shipping fees attached, they're still less than half that of the LCD where the LCD gets free shipping. | LCD monitors cost triple the price of the CRT equivelent before taxes and shipping. An LCD supporting 1600x1200 costs $450 or so when the CRT version is only $150. |
| Desk space required | -1.7 | CRT monitors are space hogs. They use up a huge amount of space, close to ten times that of an LCD of the same capabilities. Space, however, isn't all that important to me. | LCD's, though they're the same width and height as a CRT of the same size, they are very thin in comparison, even 10% as thick. |
| Display adjustments | -1.2 | CRT monitors require a bunch of fine-tuning to get the image to dislay nicely. This, however, is a one-time-thing only though. | LCD monitors, as far as I know, don't require any adjustments, except maybe the brightness. |
| Display defects | 3.9 | CRT's have little in the way of defects. Once the monitor reaches the end of its life, the whole display is affected. | LCD monitors have dead pixels. Although I've never seen it because I otherwise never see LCD's up close, it can affect how I process my usual tasks making things difficult. |
| Weight | -2 | CRT monitors, being huge, weigh a lot. Those supporting the highest resolutions can weigh even 50 pounds. When moving things, this can be tricky to work with. | Although never experienced, an LCD monitor for the highest of resolutions would weigh about three pounds (estimated by looking at the images, 150% margin of error (and thus, don't count on it**)). |
| Electricity usage | ? | CRT monitors take about 70 watts of power for a decent one using a low amount of power | I don't know what LCD monitors have in terms of power consumption so I cannot tell. |
| Refresh rates | 1 | CRT monitors seem to support a wide range of refresh rates. The higher the resolution, the lower the maximum refresh rate is. | I don't recall the refresh rates of LCD monitors, but I think they're the same as CRT's. I always use 60 Hz anyway. |
| Overall | 30*** | I have 33 times the motive (the actual value) for getting a CRT monitor as it fits many of my needs. | LCD's have too many disadvantages to warrant the price difference they have, but even with the same price, I'm still 4.6 times more motivated to get a CRT. |
| Extremely major event / Very good day | |
| Major event / Good day | |
| Somewhat major event / Somewhat good day | |
| Normal event / Average day | |
| Somewhat minor event / Somewhat bad day | |
| Minor event / Bad day | |
| Extremely minor event / Very bad day | |