QuickWait - A faster & more accurate wait that supports smaller wait times

Resources Community Resources
,
#7

My bad, you’re totally right. The first time I read it I could’ve sworn it was just doing a while loop until time was reached.

3 Likes
#8

Running this would take around 0.01 seconds on virtually any device (I assume you mean in conjunction to some arbitrarily complex logic).

QuickWait just iterates RenderStepped:Wait(), so you might as well use that instead.

The timing is also dependent on the framerate, so you are yeilding for a minimum of 0.003 seconds.

3 Likes
#9

I mean with logic, and my point is that it will crash regardless of the device and delays will fix it.

No, not exactly it uses os.clock for smaller values, Because of Roblox’s 60 fps cap RenderStepped:Wait() is equal to task.wait() both only able to go 1/60th of a second at their lowest, while QuickWait is 1/300th of a second at its lowest.

2 Likes
#10

It would be better to spread work across multiple frames rather than cramming as much work into a frame as possible. You have the right idea with the modulo 100 thing. However, it would be a better approach to do some amount of iterations until an amount of time passes, let’s say 2 ms, and then yield for a frame. I don’t see the benefit of this “quick wait” thing. Yielding for smaller than a frame is almost equivalent to executing some process multiple times in one frame.

EDIT: you can also implement parallel processing via actors if you want to squeeze as much speed as possible, but that’s a bit unrelated to the original topic.

4 Likes
#11

Why so much code also, here is a small function I whipped up and it can wait 0.00001 of a second.

function uwait(time) local start = os.clock() repeat   until os.clock()-start > time end
2 Likes
#12

Although you can “wait” for a very short duration of time with this module, you’re not actually waiting. You’re crashing the program for x amount of time before it resumes, giving it the illusion that it’s waiting. During that millisecond-long wait, this module would run an infinite loop which takes all the processing power thus yielding every other thread until the allotted time has passed.

7 Likes
Updating faster than RenderStepped or task.wait()
#13

I really do not understand how something like this is useful, and what use cases would require it. Even if there is a use case, it’s bad practice because it literally relies on the execution speed of the cpu to wait some amount of time, and prevents other threads from running, unlike task.wait() (like @VegetationBush pointed out).

Waiting within a frame (opposed to waiting for the next frame, or some other frame) doesn’t make sense (unless we are talking about the order of execution, and QuickWait will not change the order of execution). If you need to have a wait time smaller than a frame, you should instead see it as doing multiple calculations in a single frame (for a physics engine running at 240hz for example), and time is irrelevant in that case. If time is required for whatever reason, you can just “fake” the passage of time by giving a modified time value to whatever function requires it.

4 Likes
#14

Not sure how I would have “faked” waiting when I was trying to play sounds after each other with precise timing between them. Either way the function bitsplicer mentioned is very neat and I’ve seen similar things before. Their approach would have worked but I didn’t think of it when I made the quickWait function. However, he’s function freezes if its ran for too long, mine does not. Mine does however freeze when its called to many times .-.

#15

Updated the code drastically, removing any unnecessary stuff and improving its speed even more (edited it a few times today)

#16

Welcome to another episode of how to crash your CPU with while do loops without a wait or task wait!

1 Like
#17

Doesn’t crash anymore lol, it runs smoothly even on 10 coroutines running 1000 unit tests. (edit: will crash if you use too low wait times in a while loop or too long for loop though)

2 Likes
#18

also, here’s a accuracy test I performed on higher wait times.

local quickWait = require(script:WaitForChild("quickWait"))

local toWait = 5.35

warn("quickWait(" .. toWait .. ") =", quickWait(toWait))
warn("task.wait(" .. toWait .. ") =", task.wait(toWait))
warn("wait(" .. toWait .. ") =", wait(toWait))

quickWait(5.35) = 5.350000000005821
task.wait(5.35) = 5.362722799999574
wait(5.35) = 5.365588700000444
2 Likes
#19

People (like me) have written snippets like these and I kid you not, is ridiculous. You do not need these precise timings.

What would be more better is if you write the code that relies on perfect timing to adjust it internally.

2 Likes
#20

I really did need it for what I was making. But I’m providing the code for those who might have the same need I had and not for everyone to use on all their projects as that is clearly not needed.

2 Likes
#21

Code shouldn’t need to wait for such an exact time. That’s more or less some sort of design flaw. Is it possible to tell us what the use case is?

3 Likes
#22

Sound is an interesting one. From experience though, trying to get sound to play at the same time is a real pain in the *** (I made a jank script to sync multiple speakers together).
The best option would be to change the Sound.TimePosition property of the sound so one is a bit offset from the other, and start playing both of them at the same time, but I doubt that offset will be kept, as the sound engine doesn’t want to play nice. (And this solution is what I mean by “faking time”)

Does your solution work?

Also, never ever use this for long wait times, it’s bad enough with short wait times

Though you probably noticed studio freezing for 5.35 seconds when you run this script

1 Like
#23

My thing doesn’t freeze studio unless you use waiting times below 0.01 repeatedly. Unlike “uwait” and the other provided “solutions/alternatives”.

#24

The use-case is for those who need very precise waiting (in things like audio systems which have to align properly) or those who need to wait a very small amount of time in short or no loops.

#25

This doesn’t make sense. Can you elaborate?

I don’t understand why you need to wait for such a small amount of time. If you want to run a loop x times per frame, just code that in:

for iterations = 1, 50 do
    --> code
    if iterations % 4 == 0 then --> running the loop 4 times per frame
        task.wait()
    end
end
1 Like
#26

I had to wait 0.003 seconds between the creation and playback of sounds to prevent them from sounding hacky and slow. But by running a for loop it would do it instantly and not respect the time needed between the creation, playback and removal of my sounds.

But this function, like I said many times before. Is not made for everyone. It is made for those with a need for it.