Description

Currently only works with WebGL disabled

Picture in picture is an addon for Construct 2 which allows you to easily set up viewports within your game which capture other parts of the layout. It can be used to easily create split screen games or co-op games where seeing your partners view could help (see Portal 2 for example).

The plugin adds a PiP object which is blank in the editor and is just a viewport, see the demo for example. This viewport can then be used to show any part of the current layout. So you could have a character with the scrollto behaviour and then have a PiP object in the corner which shows you another player.

Properties

Each PiP viewport has three properties:

• Capture Type This can either be set to 'Display Relative' or 'Viewport Relative' and sets the base capture area for the viewport. If the option is set to 'Display Relative' the viewport will capture the entire screen and scale it into the canvas. If the option is set to 'Viewport Relative' the viewport will capture an area the size of the viewport.
• Capture Scale This is a percentage which describes the area captured by the viewport, if the scale is 100, it will not scale the image further than Capture Type. If the scale is 50 the image displayed on the viewport will be 2x bigger than when it was captured etc.
• Capture below This can either be true or false, it sets whether the viewport will capture the entire rendered screen or just layers below it (to prevent guis being captured etc).

Actions

The PiP object has 5 actions:

• Enable/Disable viewport Sets whether the viewport is displaying what it is capturing.
• Set viewport position Sets the location to be captured by the viewport.
• Set capture type Sets the 'Capture Type' property as described above
• Set capturing below Sets the 'Capture below' property as described above.
• Set viewport scale Sets the 'Capture Scale' property as described above.

Conditions

The PiP object has no conditions.

Expressions

The PiP object has 6 expressions:

• viewportcapturebelow Returns the value of the 'Capture below' property as an integer with 1 being true and 0 being false.
• viewportcapturescale Returns the value of the 'Capture Scale' property as a float.
• viewportcapturetype Returns the value of the 'Capture Type' property as an integer where 0 is 'Display Relative' and 1 is 'Viewport Relative'.
• viewportenabled Returns whether the viewport is enabled as an integer with 1 being true and 0 being false.
• viewportx Returns the x coordinate of the position the viewport is currently capturing.
• viewporty Returns the y coordinate of the position the viewport is currently capturing.

Download

Looking at the SDK manual I can see that I can scroll to a coordinate on the layout using:

layout.scrollToX(x);

layout.scrollToY(y);

However, the manual doesn't mention how to get the current scroll coordinates. I believe this is possible, why shouldn't it be?

EDIT: By doing a quick lookup one can easily find that there are parameters to layout for scrollX and scrollY. One would think this should be documented under the SDK part of the manual?

Here is a small example:

https://dl.dropboxusercontent.com/u/706 ... shing.capx

If you're running a high end computer which can run your game with ease, you can run a virtual machine and reduce it's specs until the game does not play properly anymore.

Give the player pathfinding, have an event for when the mouse is clicked to set the pathfinding to that point, then when the path is found make the player walk the path.

Can you re-post with the new events?

https://dl.dropboxusercontent.com/u/706 ... Issue.capx

Fixed the mvce as so

Can you post an mcve?

post the capx or a screenshot of the events?

blackhornet Thank you, this helps a lot! However, I still think it would be better if this could be used more intuitively.

If you are working on a big project though, you may need a lot of variables and if they are all global like they are now surely they start to become disorganised and begin to impact workflow.

LittleStain Would that work though? Setting a constant limit to how zoomed out the map could go would be a bad thing for players with both large and small resolutions. To cater for all resolutions with this surely the zoomout would have to be small so those with large resolutions don't see outside the layout by zooming out too far. But then those with small resolution would not be able to zoom out so much as to make the zoom useful.