# more efficient line of sight on tilemap?

Get help using Construct 2

### » Wed Feb 17, 2016 1:57 pm

Hi,

i need to check if NPCs on my tilemap can see each other.
my problem is that the built in line of sight behaviour is way to cpu consuming for my project.
here is how i did it, make a second tilemap with all the sight blocking obstacles, make this tilemap solid, then use LOS behaviour and bam this game isnt build for running on mobiles :/
i think the los bevaiour is way to powerfull for my needs and im pretty sure there are many many algorithms that do that more efficiently (bresenham, raycasting) and when i read about it, it seemed so easy but im to dumb to understand any of them to do them in construct2. My floodfill approach did either too much or to less, i dont get how to check if the tile isnt just empty but also seeable from the position, so yeah, i did understand the raycasting approach but not how to build it.
My dream would be that i overlooked an plugin where i just specify the range of sight in tiles, blocking obstacles and then use it

can anybody help me? im not a native speaker so its possible i overlooked some good tutorials, the main problem in finding information was to me that there where so many and most of them where with complicted code that i didnt understand.
B
39
S
11
G
5
Posts: 485
Reputation: 5,365

### » Thu Feb 18, 2016 12:24 am

Your method seems OK. Do you have a example capx?
B
60
S
30
G
133
Posts: 1,942
Reputation: 74,861

### » Thu Feb 18, 2016 1:47 am

right now, i just have a broken mess and a theoretical concept that lacks the knowledge of how to implement it in an algorithm.
The best approach i had till now was to make a function that gets four parameters (X & Y of the tile to check, direction and an loopindex to controll the distance of view).
The function then checks if the tile is ground or wall, if ground then this tile is seeable and if the loopindex isnt too high it will call the function again to check the next tile in that direction. That works for four directions, if a blocking element is found it will stop to look further in that direction. But there arent just four surrounding tiles, there are 8 and all my approaches to also check the other tiles AND stop looking further when a blocking element where found didnt work.
B
39
S
11
G
5
Posts: 485
Reputation: 5,365

### » Thu Feb 18, 2016 1:53 am

I meant the line of sight behavior approach should be sufficient, also not too heavy unless you really have tons of objects, so I wanted to see how badly it was lagging and if there was anything else causing the lag.
B
60
S
30
G
133
Posts: 1,942
Reputation: 74,861

### » Thu Feb 18, 2016 2:44 am

heres my approach http://fldr.de/lostest
here it is with los behaviour, even in this striped example you can see the cpu spikes http://fldr.de/lostest2
here is a capx http://fldr.de/lostest.capx
B
39
S
11
G
5
Posts: 485
Reputation: 5,365

### » Fri Feb 19, 2016 1:30 am

Both examples don't have much impact on my cpu. I would recommend sticking with the LOS behavior. It runs smoothly on my phone as well.
B
60
S
30
G
133
Posts: 1,942
Reputation: 74,861

### » Thu Apr 07, 2016 9:00 am

@fldr The game runs fine here as well. No high CPU detected. By the way, how did you make the LOS a cross on http://fldr.de/lostest
B
15
S
7
G
34
Posts: 55
Reputation: 18,478

### » Fri Apr 08, 2016 8:39 pm

its also in the capx above, its everything that is disabled in the event sheet but beware that this isnt a full line of sight, it only checks to four directions. And trust me, both solutions arent good for use, they will make your phone hot and youre battery empty if you use them in a game context where it doesnt only have to check this for one sprite.
B
39
S
11
G
5
Posts: 485
Reputation: 5,365

### » Tue Apr 12, 2016 8:21 am

fldr wrote:its also in the capx above, its everything that is disabled in the event sheet but beware that this isnt a full line of sight, it only checks to four directions. And trust me, both solutions arent good for use, they will make your phone hot and youre battery empty if you use them in a game context where it doesnt only have to check this for one sprite.

I see. Thanks for the heads up.
B
15
S
7
G
34
Posts: 55
Reputation: 18,478