Map Intro Camera - Like Unreal, etc.

[Baker]

Back whenever the original Unreal came out, I thought the lighting was incredible and the way the camera arced and twisted through the map.

Now camera experimentation has been done in Quake with the CamQuake (Quakeworld) engine and most of that stuff found the way into ezQuake.

But after messing around with the Quake2 #ifdef stuff that changed the progs.dat global fields and after playing around with FragMachines tutorials, I can't see any reason to not play around with adding a couple of fields into the progs globals indicating an optional intro camera and have some sort of cue on how it moves to the next point (making good use of cos, sin and tan might give it some feel).

I think some of these small things could make the ambiance of total conversions feel a little "richer".

Another thought ... it might be interesting to play around with say chase_active 2 (see Frag.machine's tutorial) and maybe changes in the camera value don't take full effect immediately and maybe the camera transitions from point to point.

And without bothering with making new SVCs or what not or using QC, it might be interesting to make some cheapy stuffcmd trigger fields that switch the chase_active distance values.

For example, maybe you enter a room that is rather linear and a trigger_multiple toggles a perspective camera change to deal with whatever situation you are in.

And maybe something like chase_active 4 has a bit of sway like how Kurok and possibly Qrack have idle_sway.

I find it a bit annoying that as far as I can tell this kind of experimentation in Quake hasn't been mainstream and the game is rather mature at 14 years old. Perhaps in part because people were so "effects oriented" during the modding golden age with engines like Tenebrae and such and the nature gravitation towards "graphics" but a richer atmosphere isn't all about effects but also ambiance.

[frag.machine]

Another thought ... it might be interesting to play around with say chase_active 2 (see Frag.machine's tutorial) and maybe changes in the camera value don't take full effect immediately and maybe the camera transitions from point to point.

Yeah, I already thought about adding some lerping to camera transitions. Nothing really hard to do actually, that would be definitively cool in some cases, but annoying in others, so maybe is better to use another value of chase_active (3 ? 4 ?) for lerping-enabled mode.

[mankrip]

In my opinion, cameras should always been coded as QC entities, and their mods should be run on engines that support 16-bit angles.

Engine-side cameras are only useful for closed-source mods that doesn't have QC cameras.

QC-coded cameras makes the server send the correct PVS data to the client, and since they're QC entities the coder have complete control over their physics attributes, like clipping, distance, angles, and speed. Plus, by coding them in the QC you can be sure that its behavior should be consistent across all clients.

Hmm... yeah, messing with idle_sway can be fun. I did this for JoyMenu, but it's been so long ago I completely forgot about it.

I thought about adding an option in Makaqu to make the viewmodel sway, but ultimately I thought it would make more sense to implement support for letting the QC code define the viewmodel through an .entity field. If I recall correctly, DarkPlaces and other engines already have this.