Yes I've noticed the lag, particular in the beginning of the scene with the transparent wall; it gets a bit worse as more npcs are added. I was a bit zealous in making the scene too large with too many objects in that small area.
I wanted to make this scene bigger than it currently is, but after noticing the lag I've changed my strategy and will start branching off into different scenes rather than continuing to add to this one.
you can also try to dlete objects to far away to see and recreate them when approaching. Like you have external layouts and zones, and when you get too far away from a zone, it deletes objects in it, and when approaching it again recreate from exernal layout
I also want to do some comparisons to see how I can achieve the highest frame rate.
Noticing the lag as I put in more objects, I started to use just 1 object (what I call the faceless npc) and shade it, but it occurs to me that from what I've learned of GDevelop, one area it typically does really well is in handling lots of objects. I've heard of some people with thousands of objects in a scene with no lag - so I may have been counterproductive. I want to make 2 different experimental scenes, 1 with 10 different npc objects, the other with 10 of the same npc object shaded differently and see what gives me the highest frame rate.
With some advice from https://mikhail-pomaskin.itch.io I was able to consolidate some code. I was running the events that move and scale the objects 4 times, once for each type of object. I've consolidated all the objects into a single group and now running the events once for all objects which gave me a noticeable improvement. It could still be better, but I noticed it immediately.
Typically I am able to run on my dilapidated hardware about 30 fps - which may not seem very good, but given that it's displaying 3d in a program that was never meant to display 3d, I think that's not too bad.
Regarding deleting/creating objects - I was doing something similar trying to fix some display issues. I was using the objects scale to determine when to hide an object. It didn't seem to affect performance in any noticeable way.
I wonder if it would be good to employ this method of deleting and creating objects on the fly depending on distance from player, but perhaps run it only every second or two to conserve resources. Or maybe delete the objects in every frame, since that seems less cpu intensive, then create the objects as needed once every second.
So far the best thing to do is to move the wall sprites where the player is looking with the help of "rays". And I also reduced the number of "bases" and wall sprites. There is an example of this optimization:
there are only ~ 700+ (wrong in the first time) bases and 720 wall sprites. Sorry for my English))
I tried using distance and raycasting but it didn't go very well for me, it made the lag worse. perhaps the raycasting was too broad? I've not used it before (raycasting) so perhaps I wasn't using it the best way.
I really like the idea of using a single base to make multiple wall sprites.
Deleting objects may be overkill indeed, but it would definitely be worth it as each objects gets lots of calculations applied to it for the 3D effect.
What I recommend doing is doing a big hitbox arround the player as field of view. Only apply the mathematics to objects in collisions with that FoV object and hide the others to not generate anyy visual glitches.
This trick should greatly improve performance. Then maybe you already have something like that in your code, as it’s the most obvious and basic optimization…
I was actually just working on this now. It not only helps improve performance but gives it a nice creepy effect with the shading around the players field of view.
Regarding the slow-down when approaching corners due to the multiple rays hitting: I have been working to make npcs appear, and have figured out a way. I put the npc images as animations of the walls, then set an instance variable for the ray obstacle for the npc, which passes from the obstacle to the sensor to the wall with an extra condition during wall creation. I put an npc in a corner, and it helps the lag a little by deflecting some of those rays from hitting the same spots.
However, it creates a minor display bug in the wall behind the npc, since the rays don't pass through it.
← Return to pure goodness
Comments
Log in with itch.io to leave a comment.
this is really cool
Really nice! Sometimes a tiny bit laggy but I love the general style and phylosophy behind it! Keep up the good work!
Yes I've noticed the lag, particular in the beginning of the scene with the transparent wall; it gets a bit worse as more npcs are added. I was a bit zealous in making the scene too large with too many objects in that small area.
I wanted to make this scene bigger than it currently is, but after noticing the lag I've changed my strategy and will start branching off into different scenes rather than continuing to add to this one.
you can also try to dlete objects to far away to see and recreate them when approaching. Like you have external layouts and zones, and when you get too far away from a zone, it deletes objects in it, and when approaching it again recreate from exernal layout
I also want to do some comparisons to see how I can achieve the highest frame rate.
Noticing the lag as I put in more objects, I started to use just 1 object (what I call the faceless npc) and shade it, but it occurs to me that from what I've learned of GDevelop, one area it typically does really well is in handling lots of objects. I've heard of some people with thousands of objects in a scene with no lag - so I may have been counterproductive. I want to make 2 different experimental scenes, 1 with 10 different npc objects, the other with 10 of the same npc object shaded differently and see what gives me the highest frame rate.
With some advice from https://mikhail-pomaskin.itch.io I was able to consolidate some code. I was running the events that move and scale the objects 4 times, once for each type of object. I've consolidated all the objects into a single group and now running the events once for all objects which gave me a noticeable improvement. It could still be better, but I noticed it immediately.
Typically I am able to run on my dilapidated hardware about 30 fps - which may not seem very good, but given that it's displaying 3d in a program that was never meant to display 3d, I think that's not too bad.
Regarding deleting/creating objects - I was doing something similar trying to fix some display issues. I was using the objects scale to determine when to hide an object. It didn't seem to affect performance in any noticeable way.
I wonder if it would be good to employ this method of deleting and creating objects on the fly depending on distance from player, but perhaps run it only every second or two to conserve resources. Or maybe delete the objects in every frame, since that seems less cpu intensive, then create the objects as needed once every second.
Thank you for your ideas :)
I tried a similar solution (removing / creating walls depending on the distance), the result was not very goodthe - fps increased, but was not stable.
So far the best thing to do is to move the wall sprites where the player is looking with the help of "rays". And I also reduced the number of "bases" and wall sprites. There is an example of this optimization:
there are only ~ 700+ (wrong in the first time) bases and 720 wall sprites. Sorry for my English))
I tried using distance and raycasting but it didn't go very well for me, it made the lag worse. perhaps the raycasting was too broad? I've not used it before (raycasting) so perhaps I wasn't using it the best way.
I really like the idea of using a single base to make multiple wall sprites.
Of course, there may be another solution, the idea of controlling the drawing range using sprite scaling did not occur to me, i trying this later))
Deleting objects may be overkill indeed, but it would definitely be worth it as each objects gets lots of calculations applied to it for the 3D effect. What I recommend doing is doing a big hitbox arround the player as field of view. Only apply the mathematics to objects in collisions with that FoV object and hide the others to not generate anyy visual glitches. This trick should greatly improve performance. Then maybe you already have something like that in your code, as it’s the most obvious and basic optimization…
I was actually just working on this now. It not only helps improve performance but gives it a nice creepy effect with the shading around the players field of view.
Regarding the slow-down when approaching corners due to the multiple rays hitting: I have been working to make npcs appear, and have figured out a way. I put the npc images as animations of the walls, then set an instance variable for the ray obstacle for the npc, which passes from the obstacle to the sensor to the wall with an extra condition during wall creation. I put an npc in a corner, and it helps the lag a little by deflecting some of those rays from hitting the same spots.
However, it creates a minor display bug in the wall behind the npc, since the rays don't pass through it.