Intersecting points at window edge/viewport?

Get help using Construct 2

Post » Sun Jan 29, 2017 12:59 am

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.
B
41
S
12
G
14
Posts: 1,117
Reputation: 11,253

Post » Sun Jan 29, 2017 1:45 am

The first thing that comes to mind would be to utilize 4 invisible helper line objects positioned at each viewport border.
Mistakes were made.
B
51
S
25
G
107
Posts: 1,581
Reputation: 60,458

Post » Sun Jan 29, 2017 1:50 am

oosyrag wrote: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?
B
41
S
12
G
14
Posts: 1,117
Reputation: 11,253

Post » Sun Jan 29, 2017 2:09 am

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).
Mistakes were made.
B
51
S
25
G
107
Posts: 1,581
Reputation: 60,458

Post » Sun Jan 29, 2017 11:11 am

oosyrag wrote: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.
B
41
S
12
G
14
Posts: 1,117
Reputation: 11,253

Post » Sun Jan 29, 2017 2:59 pm

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.
Mistakes were made.
B
51
S
25
G
107
Posts: 1,581
Reputation: 60,458

Post » Sun Jan 29, 2017 3:02 pm

oosyrag wrote: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?
B
41
S
12
G
14
Posts: 1,117
Reputation: 11,253

Post » Sun Jan 29, 2017 3:14 pm

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.
Mistakes were made.
B
51
S
25
G
107
Posts: 1,581
Reputation: 60,458


Return to How do I....?

Who is online

Users browsing this forum: tdcostas and 6 guests