This was actually implemented within 0.9.x by a user on the forum by extending me.Viewport: https://groups.google.com/d/msg/melonjs/caOfioYFMrw/_C7BD9_RoJIJ
Creating additional cameras should be an officially supported feature, allowing rendering of any source location of the scene to any destination location on the backbuffer.
Some thoughts to consider:
- All drawing operations are currently tied directly to the viewport, and are highly optimized by having only a single viewport for visibility checks.
- Any areas of the backbuffer that are not mapped to the viewport will cause undefined results to be drawn; also described on the forum.
With these in mind, I would like to propose kind of a radical change to our current viewport:
viewport vs backbuffer
- The
backbuffer is the region of the screen that is finally shown to the user. It is the area defining where pixels can be drawn. On the other hand, a viewport could be a smaller (or larger) area that renders part of the scene onto part of the backbuffer.
- The distinction is important because of cases where you might configure a
viewport that is a small part in the center of the display, but you have a border still being rendered around it (within the backbuffer). For example, this image of Wolfenstein 3D shows what might be analogous to a melonJS viewport (the 3D rendering) and backbuffer (the border and HUD):
- Another way to think of it:
floating objects are only rendered to the backbuffer. And non-floating objects may be rendered within a viewport, which may have its source coordinates moved, and its destination coordinates moved, and its source size adjusted, and its destination size adjusted. This gives full freedom of which parts of the scene get rendered to where on the viewport, at any scaling ratio.
- Thus,
viewport works like a high-level variation of context.drawImage(img, sx, sy, sw, sh, dx, dy, dw, dh) where img is the scene to be rendered with the provided source and destination parameters.
- A
viewport can obviously be rendered to the backbuffer. But I might also want to render a viewport onto another viewport. A spy game with a CCTV system could use this to render parts of the map to a "monitor" (viewport 1) on the map, which is in turn rendered to the main viewport (viewport 2) in the backbuffer. Such that I can move my spy around the map while keeping an eye on the nearby CCTV monitors to know which areas are currently safe.
- The following camera concepts map equally well to 2D space, and describe the "render a
viewport onto a viewport" scenario:
- Detailed camera system description in a 3D engine:
- Example video using Doom 3 engine : http://youtu.be/PKa4DGz1sVw
- A
viewport should be like any other object, capable of being added to the world. With the "main viewport" outside of the world, and referenced as it is today, by me.game.viewport.
This was actually implemented within 0.9.x by a user on the forum by extending me.Viewport: https://groups.google.com/d/msg/melonjs/caOfioYFMrw/_C7BD9_RoJIJ
Creating additional cameras should be an officially supported feature, allowing rendering of any source location of the scene to any destination location on the backbuffer.
Some thoughts to consider:
With these in mind, I would like to propose kind of a radical change to our current viewport:
viewportvsbackbufferbackbufferis the region of the screen that is finally shown to the user. It is the area defining where pixels can be drawn. On the other hand, aviewportcould be a smaller (or larger) area that renders part of the scene onto part of thebackbuffer.viewportthat is a small part in the center of the display, but you have a border still being rendered around it (within thebackbuffer). For example, this image of Wolfenstein 3D shows what might be analogous to a melonJSviewport(the 3D rendering) andbackbuffer(the border and HUD):floatingobjects are only rendered to thebackbuffer. And non-floating objects may be rendered within aviewport, which may have its source coordinates moved, and its destination coordinates moved, and its source size adjusted, and its destination size adjusted. This gives full freedom of which parts of the scene get rendered to where on the viewport, at any scaling ratio.viewportworks like a high-level variation ofcontext.drawImage(img, sx, sy, sw, sh, dx, dy, dw, dh)whereimgis the scene to be rendered with the provided source and destination parameters.viewportcan obviously be rendered to thebackbuffer. But I might also want to render aviewportonto anotherviewport. A spy game with a CCTV system could use this to render parts of the map to a "monitor" (viewport1) on the map, which is in turn rendered to the main viewport (viewport2) in thebackbuffer. Such that I can move my spy around the map while keeping an eye on the nearby CCTV monitors to know which areas are currently safe.viewportonto aviewport" scenario:viewportshould be like any other object, capable of being added to the world. With the "main viewport" outside of the world, and referenced as it is today, byme.game.viewport.