Investigate ways of doing split-screen cameras

[eonarheim]

In order to do this, the entire in memory canvas needs to be up for grabs for rendering. Then you take the pixels in the specific camera frustum and compose the multiple frustums together.

engine.currentScene.cameras = [camera1, camera2];

// get individual frustums
var frustum1: ex.Texture = camera1.getFrustum();
var frustum2: ex.Texture = camera2.getFrustum();

// compose cameras
var composer = new CameraComposer();

engine.currentScene.cameraComposer = composer;

This will break all off screen culling logic :/

[pathurs]

Proposal:

We shouldn't confine this feature to just 'split-screen' scenarios, we should allow different types of camera displays, in a 'Multi-camera' system.

In the above screenshot, you can see 2 players, with their own camera in a rectangle. On top of each player, they both have a mini-map, which is a separate camera that separately displays the map from each player's own position. On the bottom, a smaller version of the other player's view can be seen, for co-op style game play.

Obviously this is just an example, but I believe that allowing very custom/dynamic camera rendering would allow developers to do anything they can imagine (maybe?).

@eonarheim fyi

[kamranayub]

+100

…

On Sun, Mar 11, 2018, 04:51 Pathurs ***@***.***> wrote: Proposal: We shouldn't confine this feature to just 'split-screen' scenarios, we should allow different types of camera displays, in a 'Multi-camera' system. [image: multi-camera] <https://user-images.githubusercontent.com/3084995/37251938-31192b68-256d-11e8-908a-cff2e0514476.png> In the above screenshot, you can see 2 players, with their own camera in a rectangle. On top of each player, they both have a mini-map, which is a separate camera that separately displays the map from each player's own position. On the bottom, a smaller version of the other player's view can be seen, for co-op style game play. Obviously this is just an example, but I believe that allowing very custom/dynamic camera rendering would allow developers to do anything they can imagine (maybe?). @eonarheim <https://github.com/eonarheim> fyi — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#338 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAiaa1finLxphFJSsE0OTuNH4BYCaK6zks5tdPORgaJpZM4CfNRK> .

[eonarheim]

@pathurs Good point, I totally agree

[github-actions]

This issue hasn't had any recent activity lately and is being marked as stale automatically.

[JumpLink]

Any updates here?

[eonarheim]

@JumpLink nothing recent, there is some work going on to refactor the WebGL renderer to allow easier post processing to render targets that might be eventually useful in creating multiple cameras.

I'll slot this into our v1 roadmap, but no promises on a timeline. This potentially will require some plumbing changes in Excalibur to allow multiple cameras, running the draw routines per camera, and compositing the results together.

Tentatively I've placed this on v0.27.0 #1161

[JumpLink]

A possible workaround would be to create several canvas elements / engine objects for a split screen. In this way you would be forced to outsource the multiplayer, but that could also be an advantage, as you could also implement online multiplayer in this way (as if you had several browsers open more firmly). In addition, it would be possible for the players to be able to move around in different worlds, even on the split screen. What do you think?

[eonarheim]

The current recommendation is to use multiple instances of excalibur once v0.28.0 drops which supports that.

Closing for now, I think we'll potentially revisit this as a post v1 feature