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.
i experimented with rays:
https://drive.google.com/file/d/1jJyTYdmz-OF-YaZR92Z7nWxZ6ngkFcKC/view )
And to create many sprites on one "base" i used "sprite points"
For me this example didn't work as good, it is a slight drop in frame rate (1-2fps) compared to no raycasting. [edit] correction, there was a vast improvement in fps. I was using the example improperly. When I changed the animation to the textured wall it improved dramatically. Amazing work!
I haven't tried to make a projectile yet but I've thought about it quite a bit.
I'm curious what you mean by sprite points. Do you store the coordinates in object variables for the walls to be created? [edit] I looked more at your new example and I think I see what you mean. You're using the sensor to create the necessary objects when it hits the walls. I think this is what you mean?
I had thought of making 4 types of wall base for walls facing north, east, south, and west, then creating 8 at a time in a "repeat" condition
This example is "dead end" since texturing with bugs. I just wanted to show you how to create "rays". By "sprite points" I mean this:
I think I still need to learn a great deal more before I can understand it. But it's fun to tinker with.
I notice I've been able to have up to 48fps in this version but as you say it lacks some consistency. I notice for me the place it has the hardest time is when you get close to walls, particularly corners.
I wonder if a perimeter around the projected walls to keep the player from getting too close to get a more consistent fps.
In this example, slowdown occurs when close to walls due to the placement of the "wall sprites". There are 181 rays and 181 "wall sprites". A "wall sprite" is "attached" to the end of each ray, therefore, when you come close to the wall, all the "wall sprites" are practically at the same point, since the rays "flow around" the obstacles that you create in the editor in 2D view.
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.
