Post by dancewiththedevil in Inner Demons Dungeon Crawl comments

Viewing post in Inner Demons Dungeon Crawl comments

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 :)

Mikhail_Pomaskin4 years ago(+1)

I tried a similar solution (removing / creating walls depending on the distance), the result was not very goodthe - fps increased, but was not stable.

Mikhail_Pomaskin4 years ago (1 edit) (+1)

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))

dancewiththedevil4 years ago(+1)

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.

Mikhail_Pomaskin4 years ago

i experimented with rays:

(The project file here:

https://drive.google.com/file/d/1jJyTYdmz-OF-YaZR92Z7nWxZ6ngkFcKC/view )

And to create many sprites on one "base" i used "sprite points"

dancewiththedevil4 years ago (2 edits)

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

Mikhail_Pomaskin4 years ago (1 edit) (+1)

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:

dancewiththedevil4 years ago

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.

Mikhail_Pomaskin4 years ago

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.

dancewiththedevil4 years ago

Maybe it would help to make an object to thin the amount of rays sent out when you approach the wall would minimize the issues? Like if you are in collision with an object near the corner you send out 50% amount of rays.

Mikhail_Pomaskin4 years ago

Perhaps, but today there is no time to check. Try testing the second optimization. I have sent a private message to the Gdevelop forum

View more in thread

Mikhail_Pomaskin4 years ago

So I abandoned this method

dancewiththedevil4 years ago (2 edits)

It may not be ideal for what you are doing. Yours is a first person shooter. For what I'm doing, I don't need a lot of action components. I made a perimeter around the walls, and took out all of the extra stuff. I was able to maintain an almost consistent frame rate ~38-41.

I am going to try and see next if I can figure out how to broaden the ray to give a wider perspective, and see how that acts.

[edit] upon trying the broader perspective I am unsatisfied with the gaps that appear from the thinning rays. I may try wider tiles. I'm undecided at this point. I do like to experiment with it; it is a vast improvement over the previous method.

Mikhail_Pomaskin4 years ago (1 edit) (+1)

Yes, the perspective can be changed using the number of rays and the variable "Angle_step" For example, in the screenshot, the perspective is set to 180 degrees. If you take 181 rays and a variable of 0.5, then there will be 90 degrees, etc.

Mikhail_Pomaskin4 years ago

It's hard for me to explain, English is not my language. I will post a simplified example of the second optimization method and you will look at the frame rate

Mikhail_Pomaskin4 years ago(+1)

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))

arthuro5554 years ago

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…

dancewiththedevil4 years ago (1 edit)

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.