Page 1 of 1
Detecting differents zones performance wise
Posted: Sun Aug 06, 2023 11:17 pm
by Firnyx
Hi guys, I want to set two type of zones ( inside/ outside) where light behaviour and others thing will change depending on which zone it is. does setting several collisionpolygon2D (at least 1 for each area) for detecting that in the whole level is ok performance wise ? Or does disabling monitoring and monitorable helps ? currently using segmentshape2D on each entrance to switch, but after putting some I have realised it causes a bug and it might be tedious to use if there is too much. (Using Godot 4.1)
Re: Detecting differents zones performance wise
Posted: Mon Aug 07, 2023 11:11 am
by Tomcat
I don't suppose anyone can give you a definite answer to that question. Godot 4 is too young engine and is constantly being optimised. So the most reliable way is to investigate it yourself.
Re: Detecting differents zones performance wise
Posted: Mon Aug 07, 2023 5:22 pm
by stayathomedev
Firnyx wrote: ↑Sun Aug 06, 2023 11:17 pm
Hi guys, I want to set two type of zones ( inside/ outside) where light behaviour and others thing will change depending on which zone it is. does setting several collisionpolygon2D (at least 1 for each area) for detecting that in the whole level is ok performance wise ? Or does disabling monitoring and monitorable helps ? currently using segmentshape2D on each entrance to switch, but after putting some I have realised it causes a bug and it might be tedious to use if there is too much. (Using Godot 4.1)
What's the overall construction of the inside/outside setup? Are you only able to go in and out at certain locations?
Re: Detecting differents zones performance wise
Posted: Mon Aug 07, 2023 6:01 pm
by Firnyx
Dark gray area is inside and light gray area is outside (picture), and I could add some outside area anywhere in the level. I was wondering if putting a big collisionPolygon2D , which would cover all the inside area only to detect where the player is, isn't a bit overkill though it would be easier. I'm a beginner in game dev and I discovered my pc already struggles with too much light effects, so I'm concerned about optimization, but have no idea how much putting collisionPolygon2D cost performance wise.
Re: Detecting differents zones performance wise
Posted: Tue Aug 08, 2023 8:32 pm
by Owen Lloyd
If I understand it correctly you want to know if your sprite is inside or outside and use lighting as required.
This suggestion is simplistic but could you not use an invisible texture (similar to the image you show here) and detect the colour of the pixel under the sprite/cursor position to determine this? Eg black = inside, grey = outside?
I guess that depends on the size of your zone, but if massive perhaps you could scale down the texture and make sure your actual zone has light/dark changes on a multiple. Eg, if detection 'map' is 1 tenth scale, only have a switch between inside/outside on a multiple of 10 and check sprites position / 10.
Re: Detecting differents zones performance wise
Posted: Wed Aug 09, 2023 3:32 am
by Firnyx
Thanks for your suggestion ! So If I understand your solution about multiple it's like putting the junctions only at predefined positions as if I was using a tilemap for these transitions, which would allow to check it less often. I like these ideas but I may try to implement them later because I would like to stay with an easier solution for now.
Re: Detecting differents zones performance wise
Posted: Wed Aug 09, 2023 5:43 am
by Owen Lloyd
Yes. "Tilemap' is a good way to describe what I was trying to describe!
And yes, your junctions would be at exact X multiples of whatever ratio 1:X you were using. I hope you find a good solution and please share when you do I would to learn.
Re: Detecting differents zones performance wise
Posted: Sun Aug 13, 2023 11:07 pm
by Firnyx
Or instead of adding an invisible texture as Owen Lloyd suggested, maybe there is a way to make the player scene know where it is from the tilemap ? And then it detects if it is on the dark gray tile or light gray tile .