most likely, it sure is possible
This code doesn’t run faster than heartbeat. The least you can wait is your framerate. None of the code actually works to it’s desired purpose.
For example, if you do wait(0.01)
, it’ wont actually wait 10 milliseconds, but 16.6 milliseconds (assuming you’re running at 60 FPS):
local start = os.clock()
task.wait(0.01) -- We're trying to wait 10ms
print(os.clock() - start) -- 16.6666... ms assuming you're running at exactly 60FPS. As you can see, this is not 10ms
Oh yes it is
it does work on my testing though… it works too good, it actually does it in the correct timing (600 rpm or 10 per second)
also, please refer to this post A function that allows you to wait in milliseconds - #5 by reimakesgames
This thread doesn’t even contain the right information. Just because you “wait” shorter (even though you don’t) doesn’t mean it’s better to generate terrain this way. You also stated that you shouldn’t wait like this in loop, which is literally what this thread is doing:
repeat
dt = task.wait()
until os.clock() + dt >= NOW + Time
@reimakesgames task.wait
runs after the heartbeat step:
And because heartbeat runs at your framerate, this function never actually runs faster than 60fps. This also means that this code would do exactly the same thing:
local RS = game:GetService("RunService")
local function MiliWait(Time)
local start = os.clock()
repeat
RS.Heartbeat:Wait()
until os.clock() - start >= Time / 1000
end
local start = os.clock()
MiliWait(1) -- Waiting 1 millisecond
print(os.clock() - start) --
If you just use the code above, it will do the same thing. It will probably run faster because it’s more optimized than what you provided. task.wait
is basically a shortcut to RunService.Heartbeat:Wait()
:
As you can see in the video provided, it doesn’t wait 1ms, but 71ms.
Actually, I see my module faster than task.wait and heartbeat,
And heartbeat is still slow for terrain generation while my module is way too fast.
I have also benchmarked your custom wait function and it doesn’t wait the appropriate time much like roblox’s one when you try to wait a shorter time than the pipeline executes at
local function MiliWait(Time)
local NOW = os.clock()
local Time = Time * 0.001
local dt
repeat
dt = task.wait()
until os.clock() + dt >= NOW + Time
repeat
if true then end
until NOW + Time <= os.clock()
end
local TaskWait = task.wait
local cachedTimes = {custom = 0, integrated = 0}
for _ = 1, 500 do
local startTime = os.clock()
MiliWait(1)
cachedTimes["custom"] += os.clock() - startTime
end
warn("Custom Completed")
for _ = 1, 500 do
local NewStart = os.clock()
TaskWait(.001)
cachedTimes["integrated"] += os.clock() - NewStart
end
warn("Integrated completed")
warn(cachedTimes)
16:32:15.619 Custom Completed - Edit
16:32:23.953 Integrated completed - Edit
16:32:23.953 ▼ {
[“custom”] = 8.463101300178096,
[“integrated”] = 8.33417210020707
} - Edit
It seems to me like your custom implementation is slower than roblox’s one as well as not completing what it is advertised to do
Where’s my module code supposed to be in the code?
Have you tried measuring that speed
At the top of the code snippet, I removed all the comments from it
local function MiliWait(Time)
local NOW = os.clock()
local Time = Time * 0.001
local dt
repeat
dt = task.wait()
until os.clock() + dt >= NOW + Time
repeat
if true then end
until NOW + Time <= os.clock()
end
This? This is not the module code,
It should be as I got it from your post
EDIT:
Image is here: https://gyazo.com/7c5605d7069bd6c6cedd28a37db400aa
well try repasting my code and measure the speed
Uhh dude, not her module, my module.
Your module isn’t actually a wait module as it doesn’t yield the thread at all, so if you were to put it into a while true do it would crash studio( like it is doing to mine right now), you’d be better of not using it at all as there is no way for it to wait until a specified time has elapsed and no other scripts would run at the same time as the thread scheduler will keep running this thread until it crashes.
also I thought you were this post’s creator and you shouldn’t be plugging you’re own post in another person’s post
To me it does. I can show proof later
Try to mess with the second argument, you’ll see a difference
10 times per second is easy - you can do that with task.wait(). Try doing it 200 times per second. It won’t be able to do it properly, since it’s still based on Heartbeat.
why do you keep saying heartbeat is still slow for terrain generation? are you doing this?
while true do
for y=1,200, do
for x=1,200 do
--perlin code
task.wait()
end
end
end
maybe instead of spamming wait() to “garbage collect” how about you decrease your space complexity to avoid running out of memory (or just turn off script timeout lol). How? well how about making it one loop, saves LOADS of ram usage. Also, please don’t tell me you are doing some crap like this
for y=1,200, do
for x=1,200 do
local perlinNode = Instance.new("Part")
--[[
perlin properties
]]
perlinNode.Name = tostring(x).."."..tostring(y) -- uh oh
perlinNode.Parent
--perlin code
task.wait()
end
end
while true do
for y=1,200, do
for x=1,200 do
local perlinToModifyPosition = workspace[tostring(x).."."..tostring(y)] --kms with this datamodel overload
--perlin code
task.wait()
end
end
end
instead, use a god damn hashmap! (fancy word for dictionary)
sorry if i seem harsh but i have experience in doing computationally expensive stuff like that in roblox
used to, now when i used heartbeat its still slow, so i use my method.
yea but dude you will get better performance not using your method at all at that point
What’s the benefits of using this over something simple like the below?
local function MiliWait(Time)
return task.wait(Time / 1000)
end