You are wrong.
while task.wait() do
end
and
game:GetService("RunService").Heartbeat:Connect(function()
end)
are the same performance wise
1 Like
but i don’t mean task.wait is laggy
loop is problem, loop need more performance to do, and heartbeat as i know runs every simulation, not every frame, soo if there’s no simulation complete, no function will run
Reply from DF:
It ignores the wait because it is an event, it runs everything the condition for the event to happen it met, in the case of heartbeat, physics have been calculated and so it runs the event, and once another event happens, it’ll run that code separately, unlike a while loop which respects waits,
You need to debounce the event to make it work like a while loop, respecting waits and what not
what about ContentProvider ???
This example is just BindableEvents than trying to explain how you should preload assets here.
Humanoids are not the reason game lags, it’s the DEVELOPER that codes it all and those listed in there are also not the reason to blame.
1 Like
trust me, 100 humanoids lag the game, i tested it myself
The real optimization comes from looking at the micro profiler.
What is good to know is the balance between easy to maintain and readable code versus optimized code.
Deprecated functions aren’t often way slower than newer alternatives
1 Like
The reply from Roblox staff that I quoted says it doesn’t.
I don’t know what a DF is and what that even means.
It’s both. Too many Humanoids are harmful for game performance since it has to manage a lot of different characters at the same time, but the developer’s own coding and implementations also play a huge factor as well
4 Likes
some functions are better to use, for example findPartOnRay vs Workspace:Raycast, or task.wait() vs wait(), or maybe object like body movers - they are good but sometimes they goes badly
Yeah, they are nicer to use, but not necessarily faster. task.wait() is better because it can yeild for 1 frame minimum while wait() only yeilds for 2 frames minimum, can’t yeild for only 1 frame. For FindPartOnRay versus WorldRoot:Raycast, I do not know their performance, but I do know that in the case of the (almost deprecated) GetTouchingParts versus WorldRoot:GetPartsInPart, the newer alternative isn’t really faster
Discussion from Introducing OverlapParams - New Spatial Query API:
WorldRoot uses more optimized collision detection, however, it hasn’t been benchmarked against Region3. So how much faster? idk
For body movers, from what I remember (couldn’t find my sources), BodyMovers run at 240Hz regardless of the Adaptive Timestepping, which will reduce performance if you have a lot of them
The usefulness of the new AlignPosition and AlignOrientation objects can be argued…
1 Like
You can only have the HumanoidRootPart and the Humanoid in the server while the client will handle the rendering part of all bodyparts and animations
Hypothetically speaking, you can have 500 or more humanoids with proper implementation, such as unrendering the bodyparts after the humanoid is 500 studs away from the camera and stopping animations after the humanoid is 250 studs away from the camera
2 Likes
Adding performance settings is great, even if roblox already adds that. This can make people be able to play your game at full graphics, for example, in my old pc I was able to play at max settings, but my pc hated the Depth Of Field effect and wasnt able to hit 60FPS, so having a setting to disable it would be good to be able to play it max graphics without compromising the other visuals
1 Like
well, you didn’t read this part anyways
I’m not really sure if this is still true or not, but I heard somewhere on the devforum, a long time ago, that neon was actually one of the fastest materials on roblox. Supposedly, it’s because roblox doesn’t perform specular / defuse calculations on it or something like that, but I don’t really remember.
1 Like
oh, maybe they changed that, it used to be laggy, maybe they fixed that, if yes, take this as outdated point
Thank you for your service! Will for sure use these tips in the future!
2 Likes
With the humanoids, does this also include the ones inside replicatedstorage or just the workspace? Since I use replicatedstorage to store charactermodels
1 Like
The main problem with humanoids is that they need to replicate a lot of propertiess, store them in server storage to avoid potential lags
It cannot be serverstorage because it must be accessable by the client. I guess an alternative way is just to get a dummy then add body colours and acessories etc all inside a module script, then having a function spawn a dummy then apply them all based on the data in module. Is that the best way for optimisation?
Update:
I tried to transport server storage instances to client, however they must both be accessible.
This is pretty much structure optimization, but what you want to do is store data that client needs and cannot be accessed by other way (via script or smth) or it’s the simpliest way to do it