How to maintain 60 FPS?

Help and Feedback Scripting Support
, ,
#1

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.

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

  2. What is the issue? Large amount of parts ruins FPS, especially when they are being moved.

  3. 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)
7 Likes
#2

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.

3 Likes
#3

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?

2 Likes
#4

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.

2 Likes
#5

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
#6

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

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
#8

Could you give me an example of what ipairs looks like?

1 Like
#9

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
#10

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.

2 Likes