Camera Objects: Brainstorming
<i>This post was originally made by <b>danij</b> on the dengDevs blog. It was posted under the categories: Engine, Games, Version 2.0.</i>
A quick inspection of the current state of multiple local player support in the Beta6 branch reveals it to be mostly working. All UI and HUDs are now handled independently and rendered correctly. In fact it seems (other than the unified networking side of things) the only remaining hurdle is the camera interpolation/smoothing and per-frame parameters such as the view filter, which now need to be handled independently for each (local) player/viewport.
Next step for this as I see it is to separate the concepts of player/camera in Beta6.11
Lets do a little brainstorming before compiling a formal proposal.
One approach would be to use the Mobj system with the engine predefining a new Mobj type for use as a Camera. This would allow all Cameras to work within the existing subsystems with little change and allow games fine-control over their behaviour. Client-side movement of the Cameras would therefore be included in demos automatically. Camera Mobjs would follow whatever other Mobj they are set to track with an engine-side Thinker (fractional timing) handling movement. When drawing the world in a viewport the game would specify the Camera Mobj rather than the player number.
Open questions:
Are Cameras local-only or does the server need to monitor them (potential for spying)?
A quick inspection of the current state of multiple local player support in the Beta6 branch reveals it to be mostly working. All UI and HUDs are now handled independently and rendered correctly. In fact it seems (other than the unified networking side of things) the only remaining hurdle is the camera interpolation/smoothing and per-frame parameters such as the view filter, which now need to be handled independently for each (local) player/viewport.
Next step for this as I see it is to separate the concepts of player/camera in Beta6.11
Lets do a little brainstorming before compiling a formal proposal.
One approach would be to use the Mobj system with the engine predefining a new Mobj type for use as a Camera. This would allow all Cameras to work within the existing subsystems with little change and allow games fine-control over their behaviour. Client-side movement of the Cameras would therefore be included in demos automatically. Camera Mobjs would follow whatever other Mobj they are set to track with an engine-side Thinker (fractional timing) handling movement. When drawing the world in a viewport the game would specify the Camera Mobj rather than the player number.
Open questions:
Are Cameras local-only or does the server need to monitor them (potential for spying)?