Why if I use while true do wait() Camera.CFrame = Engine.CFrame end the Camera looks laggy?
because wait(), use game[“Run Service”].Stepped:Wait()
Yeah thanks, I actually solved with that rn
I don’t recommend using a while loop for your case, much less using a RunService event to serve as an interval. It’s generally not good practice to rely on the tick of a RunService event to fire. You can instead hook your setter directly to a RunService event, as is canonical for camera updates.
In this scenario, it’d be appropriate to use RenderStepped.
(cc @mistr88)
-- Use GetService to fetch services! Not their literal names!
local RenderStepped = game:GetService("RunService").RenderStepped
RenderStepped:Connect(function ()
Camera.CFrame = Engine.CFrame
end)
2 Likes
I would recommend using BindToRenderStep, which will let you control the order of which things are being done. This is useful if you need to bind other things to RenderStep without conflicts.
game:GetService("RunService"):BindToRenderStep("SomeName", Enum.RenderPriority.Camera.Value, function(dt)
camera.CFrame = something
end)
2 Likes
If you use spawn, there is not big diference
Spawn creates a pseudothread and calls the function you pass to it once using the legacy thread scheduler. There is also a built-in wait.
Connecting your function to RenderStepped will make it run every render tick, which is before physics simulation (RenderStepped → Stepped → Heartbeat). This is how camera updates are canonically handled.
1 Like
Idk if yk, but every event have 2 functions:
Connect - will run function every time it occurred
Wait - will wait before it will activate
So when it is running in different thread, we are doing same thing, I was just trying to edit the code as less I can
Only difference is, that when it will be longer, than one frame, in my solution, it will jump the next frame, but with 1 CFrame isn’t problem
Event:Wait() will yield the thread until the event in question runs. It is much better than wait, but not a solution to this issue. If his code runs slower than 60 times a second even by one CPU cycle, some frames will be dropped, causing a stutter. Heartbeat and RenderStepped will do this 10 times better as they will cause the framerate to drop in case of a slowdown, giving you a smoother experience, though RenderStepped is better for this as it fires just before the last frame is rendered.
Using :Wait() is only good for replacing wait(). The situations where it excels are functions which must run for a significantly higher amount of time than the current framerate, making it a good idea to let the frame pass from times to times.
this is why I said to run it in new thread.
Other informations
Ok I didn’t know this, thx for correcting. I used this (my solution), only when I was updating npc to view port frame, and it worked.
You can have 100 threads running at the same time, but the frame rate will stay in stable 60 FPS if they all somehow manage to complete before 1/60th of a second.
You can also have 3 threads, but you can crash the game by just having one of them hang. This is why your program will stop responding if you do a while true do end loop. Roblox does have some countermeasures for this, but they basically force the thread to stop.
A while RenderStepped:Wait() do end loop will work similar to connecting a function to it, but instead of calling the function each frame, it will wait for the current frame to finish. The main issue is that it could skip one frame in case 1/60th of a second already passed and the block in the loop still hasn’t finished. It will yield it, making the frame pass and only then will it wait for the next frame.
1 Like
yes, but i saied, that when it is too long, it can have problem wit this, but setting one cframe is ok
1 Like
Spawn is not the same as connecting a function to a signal. Connected functions run asynchronously, spawn turns up a pseudothread and runs the function immediately after a brief yield.
I’m not sure why this is a point since it’s unrelated to what I’m talking about. There are different use cases for spawn and connect. They are not replacements for each other nor are they interchangeable.
If you’re talking about the difference between spawning a loop that relies on the event firing versus connecting the function, you should be connecting the function. Waiting for the signal to fire in another loop is a reinventing of the wheel for connecting a function to a frame tick and having the engine handle the “loop” for you. It’s rather pointless to use Signal.Wait.