Intersecting points at window edge/viewport?

I noticed this great example of gathering the coodinates of intersecting lines: https://dl.dropboxusercontent.com/u/475 ... Lines.capx

How could this be modified to detect the edge of the window/viewport/camera (not layout)? It's a little hard for me to work out, since the viewport expression, unlike an object, has no angle data to extract, and there's 4 sides to work out separately.

The first thing that comes to mind would be to utilize 4 invisible helper line objects positioned at each viewport border.

The first thing that comes to mind would be to utilize 4 invisible helper line objects positioned at each viewport border.

Exactly what I was thinking, I just wanted to make sure I did it right and didn't ruin any performance by having a hulking great sprite rendering. Would it be best to use a 1px sprite resized to the width/height and positioned in place?

You definitely don't want a huge sprite, as transparent pixels require rendering as well. 4 instances of a 1 px sprite would be the way to go, with negligible performance impact (especially if positioned just outside of the viewport).

You definitely don't want a huge sprite, as transparent pixels require rendering as well. 4 instances of a 1 px sprite would be the way to go, with negligible performance impact (especially if positioned just outside of the viewport).

I'll have to fix the four instances with an every tick for my scrolling, which will decrease performance, won't it? Unless there's some behavior that keeps the object fixed to the screen regardless of scrolling, I can't use a different layer either, because I need the collisions on the scrolling layer.

You can have a lot of things moving every tick.

Of course design for your platform, but CPU is rarely the bottleneck. As commonly suggested, don't waste your time. More specifically, keep an eye out for too many physics/collision tests, which are exponential in cpu cost, rather than object position updates.

You can have a lot of things moving every tick.

Of course design for your platform, but CPU is rarely the bottleneck. As commonly suggested, don't waste your time. More specifically, keep an eye out for too many physics/collision tests, which are exponential in cpu cost, rather than object position updates.

Would a fairly frequent test for collisions on a viewport "pinned" Sprite like this every tick qualify as being hard going on cpu?

Think of it as four less objects you can move every tick (thousands?) or check collisions with normally (hundreds?), in the worst case scenario. Best case you can limit the pool of objects involved in any given collision test (https://www.scirra.com/tutorials/902/li ... raycasting), so it literally does not make a difference at all.