Add support for viewport resize / zooming

[melonjs]

@see ticket #4

[greghouston]

The idea here is to be able to zoom into the game without the viewport resizing.

In the following two examples you zoom with the mousewheel and drag the viewport with mousedown.
http://sigmajs.org/examples/gexf_example.html

Same functionality in an HTML5 game:
https://chrome.google.com/webstore/detail/fieldrunners/lkpikhjbfbffdblahfidklcohlaeabak?utm_source=chrome-ntp-icon

Additionally, this is a lot more useful if you can zoom into the game without the gui and hud zooming. See the game above for an example. I think one way to do this would be to have buffer objects that you can create and then assign other objects to. So you could assign everything accept the gui and hud to be rendered in one buffer object and the gui and hud in another. You could zoom one buffer and then have them both rendered on top of each other on the canvas.

[andyveliz]

How about some autoresizing of the viewport?

i mean, without scaling the content, adjust the viewport to show more of the map...

[melonjs]

Does any of you has any idea or suggestion on how to manage this from an API point of view ? I mean how these features should be available from an end-user point of view ?

[andyveliz]

hmm maybe the autoresizing of the viewport could be when the autozoom feature is false, and the mantainAspectRatio is false too?

[greghouston]

@andyveliz:

Autoresizing of the viewport was dealt with in ticket #4.

@obiot:

I'm not sure if it should be me.game.zoom or me.video.zoom or something else, but for shorthand I will just write game.zoom for now.

game.zoom
game.zoom.min
game.zoom.max

zoom is a multiplier. It multiplies the already autoresized viewport contents. 1 is default, no zoom.

zoom.min and zoom.max allow you to set min and max zooming, e.g., min zoom might be set to 1 and max zoom set to 2. Defaults would be null.

HUD and GUI objects should have a zoom flag defaulting to true. If they are set to false, then they will not zoom.

game.zoom = 1.5
game.zoom.min = 1
game.zoom.max = 2

myHUD_Object.zoom = false
myGUI_Object.zoom = false

On the backend, the best way to deal with this would probably be to draw HUD and GUI objects with zoom set to false on their own buffer, zoom the main buffer and then draw the HUD and GUI buffer on top of the game buffer. Originally my idea was to allow the user to create custom buffers and assign whatever objects they want to each one and assign each buffer a z-index, but that is a lot more complicated, and I couldn't think of any use cases for it. It's a lot simpler if just GUI and HUD Objects can be individually flagged not to zoom and thus there are only two buffers at most and the user doesn't deal with them directly.

[greghouston]

Alternatively, you might just have one flag for all HUD objects and one flag for all GUI objects.

game.zoom // defaults to 1
game.zoom.min // defaults to null or 0
game.zoom.max // defaults to null or 0
game.zoom.HUD // defaults to true
game.zoom.GUI // defaults to true

[greghouston]

I just thought of a situation where I'd probably want to use something other than a GUI or HUD object in the unzoomed top buffer. So it might be nice if other types of objects had a zoom flag. For instance, the user is zoomed in, and then the game ends. On top of the game I write in big letters either, "Defeated" or "Victory!". If it says victory there may be a fireworks particle effect behind the word. Even though the rest of the game is zoomed in, I wouldn't want the Victory and particle effects to be zoomed.

Obviously, using two buffers, anything that does not zoom will always be on top of stuff that does zoom. For the use cases I can think of this works well. I think they can all still use the same sort for z-index, the objects are just rendered to two different buffers.

So if I run me.game.sort and assign z-index values to everything, those values would not change even though there are two buffers, but anything drawn to the non-zooming buffer would be on top of the stuff in the main zooming buffer.

You could make it more complicated and give both buffers their own sort functions but I really don't think it's necessary.

[obiot]

i'd say that viewport resize capabilities is done !

[parasyte]

Almost. ;) It only resizes one dimension of the viewport today.

[obiot]

the flex settings yes, but the me.game.viewport.resize() function should be fully working now :P

[parasyte]

Got it! Yes, I think so, too.

[parasyte]

Zoom can be done pretty easily thanks to #704! See the following forum post for details: https://groups.google.com/forum/#!topic/melonjs/fAtFFe2wvCo

How we want to expose this to end users is an open question!

[obiot]

i think this ticket can now be closed together with #335 (see there for example) since we do now (and finally) provide a clean way to zoom and even apply any transformation to the level without impacting the viewport.