Hi. I need some tips for how to maintain 60 FPS for all devices. Granted, not every device performs smoothly and might cause FPS to drop, however that isn’t the issue. The issue is actually my game and it’s causing people’s FPS to drop.
-
What do you want to achieve? 60 FPS at all times if possible. (I know it isn’t possible, but if it’s really close to 60, that’d be great.)
-
What is the issue? Large amount of parts ruins FPS, especially when they are being moved.
-
What solutions have you thought of so far? RunService. It works pretty well, but I’m still noticing a significant drop in FPS whenever parts are moved using a script.
Alright, so as you know already, the FPS counter is taking a severe beating. Let’s say I have 100 cylinders and maybe 200 ball parts. I use RunService to make them move “smoothly”. However, they don’t move smoothly and the FPS drops to a 20 or 40 FPS. If I could get some tips on how to make parts without a severe FPS drop, I’d appreciate that.
local RunService = game:GetService("RunService")
RunService.Heartbeat:Connect(function()
for i, v in pairs(script.Parent:GetChildren()) do
if v.ClassName == "UnionOperation" then
local Unions = v
Unions.CFrame = Unions.CFrame * CFrame.new(0, 0, 5)
end
end
end)
6 Likes
if it were a little more strategic, I would specify in the topic if you have CanCollide and CanTouch activated, I recommend to deactivate it.
2 Likes
Okay. I’ll deactivate them then. They are on. I’m not sure if that is the issue though. Would that ruin an .Touched function?
1 Like
you know, if you know about physics, cancollide calculates the physics and makes hearhtbearth take longer to run or lower its repetition, if you want to activate cantouch.
1 Like
Well you can dave a table where all the parts names are “UnionAsync”
and then use runService to apply from the table from there, Also ipairs is faster than arrays so I would use those instead. This shouldn’t be an issue unless its children are changing.
1 Like
I tested the game, and CanCollide was already off. CanQuery is also off, and there was no change. This didn’t work, but thank you for the suggestion.
1 Like
and the parts detect the touch event all the time? remember that if the touch event is triggered 100 times at a time it is already a problem.
1 Like
Could you give me an example of what ipairs looks like?
1 Like
I believe it is. How do I stop that from happening? Here’s the code.
local Obj = script.Parent
local Damage = script.Damage
Obj.Touched:Connect(function(hit)
if hit.Parent ~= nil and hit.Parent:FindFirstChild("Humanoid") then
local Humanoid = hit.Parent.Humanoid
if Humanoid ~= nil then
Humanoid.Health = Humanoid.Health - Damage.Value
end
end
end)
1 Like
the truth is that I can help you very little:
local Obj = script.Parent
local Damage = script.Damage
Obj.Touched:Connect(function(hit)
if hit.Parent:FindFirstChild("Humanoid") then
local Humanoid = hit.Parent.Humanoid
hit.Parent.Humanoid:TakeDamage(Damage.Value)
end
end)
it is not necessary to verify that the father is null since most probably that happens very little, besides you verified if the humanoid is not null but in the same way you had already verified it before, to subtract the life in such a way let’s say that it did not contribute so much to your code much less when putting two arguments, although in the same way the change would be of at least 2 or maximum 5 fps more.
you have the following options, make a large part that surrounds a number of parts reducing the event from 100 or more to exactly 10, so let’s say you would save a lot, and the other option is that the event is from the HumanoidRootPart of the character, and the last one is that when the part touches it is destroyed.
1 Like