Open kalexmills opened 6 years ago
I'm thinking this should be as easy as allowing a RenderSystem
to contain multiple Camera
instances. With that, we could just loop through the Cameras and do a draw call for each one.
Sounds good.
It's likely a premature optimization, but, would it make sense to enable each Camera instance to avoid rendering in regions that another Camera is just going to overwrite later? I'm not familiar enough with low-level graphics processing to know whether this is useless optimization or not.
Not really. That said, thinking about this more, it's actually a little more complicated than what I initially proposed, as we'll probably need to support multiple viewports that the cameras will render to. Ill need to think about this a bit more.
I'm guessing Viewports are in screen coordinates, and Cameras are in world-coordinates. If that is the case, it seems to me like a good separation of concerns is this:
Viewport: defines a rectangular region of screen space as a render target Camera: defines a rectangular region of world-space as render source. Ideally, Viewports and Cameras are decoupled, so we can switch around the assignment of Camera to Viewport at run-time.
I guess the RenderSystem is responsible for actually blitting the source pixels to the target region?
This makes sense based on other game engines I have worked with. Not sure if that is a good design for engo as of today or not.
Yea, A Viewport is basically a portion of the screen. It's what defines where on the screen (0,0) is and what the width and height of the render surface is. A Camera is basically just a transformation applied to everything in the Viewport to give the player the illusion that she is viewing the scene (game world) from a certain perspective. It's a purely logical construct.
EDIT: And yea, we should definitely decouple the concept of Viewport and Camera. The RenderSystem is just a subsystem that is responsible for managing all of the viewports and cameras and using the OpenGL (or Metal or w/e) Context to render whatever RenderObjects that are passed through it.
Looking at this closer, it's not really possible to do this in a backwards compatible way, unfortunately. The reason is that much of the Camera information is stored as publicly exposed global variables. and all assumes there will only ever be one Camera. This will have to wait for 2.0.
This is a simple feature request for including multiple cameras which may render to different portions of the screen, using a picture-in-picture kind of effect.
It can be useful for split-screen gaming, mini-maps, or 'security camera' type interfaces.