About CPU usage and possible bottleneck with heavy NPC scripting
-
So this question is about the game performance when we run "gang-war" style scripts, like this one, where basically you have dozens of NPCs fighting each others, on huge battles.
I'd like to know if the FPS drops produced are some kind of GTA5 limitation (maybe because the game is originally not supposed to have that quantity of NPC fighting at the same time), or more like my CPU is not powerful enough for that.
My CPU is an AMD Phenom ii x6 1045t, which is kinda old, although most games are running OK. AFAIK there's usually no GPU bottleneck on most of them - for example, in GTA V I usually get 100% GPU usage, except on these gang war situations for example. Looking for usage stats, on one of these battles the GPU usage is around 50%, the FPS are around 30~40 (out of war I reach ~70) and CPU usage is around ~70%.
What do you think? Somebody with better CPU can tell me his experience? Thanks.
-
@EnforcerZhukov In GTAV and any video game, the performance about NPC interactions and behaviors are not limited by the hardware, is mainly about the scripting methods. Those "Bots War" mods, are not optimized, the methods used are high processing demand like "Get nearest entities", "Get all entities" and similars, those methods affects drastically the game processing.
Only using optimized methods like the game developers uses, can be done a smooth and efficient gamming experience.
I have a Phenom II x6 1100T with a GTX 1060 6GB and I always reduce the CPU clock to 1200 MHz per core and GTA V runs 720p smooth in all locations. With Gang War mods, the performance is affected drastically. Is notorious the usage of "Get entities" methods to enable the search and assign the destroy tasks in spawned peds, but exists other methods more efficient like using raycasts (capsule type) and the detection methods like detect entities in a area, in a cone or on the navmesh.
Also the "foreach" and other loops can affect the processing power when exists a lot of peds in task. Is better the implementation of coroutines to give tasks to peds without affecting too much the performance.
Finally performance problems in script mods, have just one cause: bad optimization.
-
@Rarefacer thank you for your insight! I have never heard about coroutines, and now after reading about it, I realize how helpful this is! If I understand correctly, if I used GetNearby in a coroutine, it would go through one ped every frame, rather than all peds at once?
Another thing: I was under the impression that raycast capsules were costly so I've only ever used them for camera direction stuff, and usually no more than 2 at a time. Are you saying that using multiple raycast capsules instead of GetNearby would be more efficient?
@EnforcerZhukov I've had similar frame drops with one of my old mods, Optical Camouflage; it uses GetNearby every x number of frames, can't remember what radius I used, but the fps definitely took a hit. If I have time today, I can report my fps here, with and without using coroutines on the GetNearby function (if I can figure it out). I have a i5-4440 so it isn't very powerful to begin with, but hopefully the difference will be noticeable.
-
@stillhere Yeah, coroutines are encapsuled methods under a condition, so the loop is called only when is necessary and finish when the condition is false and its processing thread is simplified, It doesn't keep repeating every frame like happens with the Get entities methods.
The Raycast capsules can be nicely used when we use debug helpers, but only the first retail version of the game has that. Is hard sometimes adjust the capsule dimentions to not get too much data about objects around. Raycasts can offer data about entities touched by the projected ray and the Get-Entities methods are based in the calculations of coordinates between the origin point and the range, comparing the entities distances inside the range, demanding more processing power.
-
@stillhere The GetNearby problem was what prompted me to write this https://forums.gta5-mods.com/topic/5499/tip-code-optimised-getnearbyvehicles-ped-process
Whilst not a coroutine in the strictest definition, it applied a similar process of collection and distribution across multiple frames, instead of all at once. Spreading the task makes a big difference with that process.
-
@LeeC2202 I remember, but I never got around to using it; most of the scripts I've worked on lately only required small radii, usually just to return the first ped that met a condition, and then I'd be done with it. But my old mod I've mentioned above, it is a perfect opportunity to test since I've been meaning to rewrite it!
I'll forego trying the raycast capsule method and instead try your method to capture the peds, then use a coroutine to go through the list and see how that works out. I hope I am understanding all this correctly though haha
@Rarefacer I see, I will try playing around with this info
-
@EnforcerZhukov Spend a day in Second Life, with every other avi running 100+ scripts simultaneously, and then you'll fully appreciate ped scripting lag.
-
Interesting topic, it also underlines a crucial point in general programming : the logic behind it.
GET_PED_NEARBY_VEHICLES, GET_PED_NEARBY_PEDS are are standard natives used when trying to collect entites in order to handle them. Yet they are the "most simple" way to achieve it. When a user has other scripts running in parallel, it can but only overload the CPU if it's called too often.This is why I never leave the entites' handles out of range. If I need to work with a huge amount of peds, I must know exactly which list they belong to and what are the instructions run behind. OOP allows it, create a separate ped class, make an exclusive ped thread for them, run the code logic inside. Any entity you want to handle must be handled by your own script before they get collected from within the game.
Unfortunately, every "beginner" jumps on pre-built functions such as
World.GetNearbyEntites
because it saves a lot of extra-time but at the cost of extra-performance.
