ā How to limit while loop updates per second amount
What i mean by the name is that: for a console application i'm developing (if you're wondering it's a game's server) i need a function something similar to say, Unity's
FixedUpdate()
, so that the function only happens somewhere like 50 times a second, because while (true)
happens every single frame. or in layman's terms: How do i limit FPS?85 Replies
you'd need to implement your own gameloop
and no,
while(true)
and any other loops are NOT every frame even in Unitythere is a PeriodicTimer which is pretty good. I don't know about it's accuracy though
but it can be set to tick every X milliseconds
it does not have the drift that a
await Task.Delay(TimeSpan.FromMillisecond(20))
would havein the context of gameloop I don' think this would be usable as is, you'd need to calc it based on display refresh rate to get 1 frame timing correctly
i have dealt with a lot of frustration regarding accurate game loop timing
standard C# timers just aren't precise enough
they said it's a game's server
i haven't found a solution that minimizes drift without some amount of spin waiting
for frame-based engine, yeah you can't just do raw c#
that's what periodictimer does
yeah, all it needs to do is send position data between the client and the server (the client is made in unity, so that's why i'm not that experienced in standalone application C# programming :D)
@Rainys What is your target OS?
Does this need to run on Windows or Linux
?
so is this Unity or nah?
you're trying to roll your own engine, right?
windows is okay, but both would be nice i guess.
Each O/S has a specific mechanism for high resolution timers
And XPlatform is a pain
game (client) is made in unity, and the server is a standalone .NET console application, so to answer your question: no
wut?
@BadaBingBadaBoom ?
bogus lol
?
PeriodicTimer is cross platform
it's the most precise and modern c# timer
unity has its own stuff for handling server stuff, no?
or like, there's dedicated libraries for it already
No
PeriodicTimer still has performance and drift issues
prove it
I don't have too lol
you can't just make bogus claims without proof lmfao
But you're welcome to "mess about and find out"
You're completely free to believe me or not
Its the internet
Everything i say could be false
š
aight, you're trolling
if it wasn't obvious before
Wut
i'm using a server system/framework or whatever you want to call it called
Riptide
. and all it basically does is allows the programmer to send "messages" between the clients and the server. However what should happen with the "messages" is all the programmer's work, but for now my question is what is the best way to implement the fixed update function thing in C#
okay, so as i understand i should look into PeriodicTimer?Wouldn't you be better off using an existing event system
it's pretty easy to use, too
What protocol does Unity push messages over?
Dude stop
like your whole program.cs is just like
so this just executes the code inside the while loop 50 times every second?
yup
what's the drift on that loop?
well, thanks, you answered my question :D
i recommend testing it to make sure the actual wait time doesn't vary too much
how should one check the drift, exactly?
with a stopwatch
i haven't used this specific timer but every other timing mechanism i've tried has been awful for delays less than the length of an average game tick
come on, send some code i can test on
i'm about to leave for work which unfortunately isn't a game studio
no clue how this would be tested
just run a stopwatch in the loop and dump the wait time between ticks
no shot that's how you tested it LMFAO
stopwatches are NOT accurate
they're more accurate than timers afaik
there's a reason we don't just use stopwatches to benchmark code
okay, what's used?
there's so much managed overhead to them
BenchmarkDotNet?
whatever they use
what does that use?
certainly not stopwatches lmao
you can't get nanosecond accuracy with stopwatches
i just did this
you complain about stopwatches then you go and use datetime?
?
surely trolling
wait, you aren't even timing
why would i
that's the point?
to make sure the simulated time matches real world time
no?
that's
what that's doing
it adds the supposed interval to the start time on each tick
if there were a delay in the tick
then the printed time would no longer match up with the real world time
where are you actually measuring time and not just adding a fixed number in that loop?
what's there to measure
you don't understand this assignment
i gotta go to work
i think you just don't understand what that code accomplishes lol
you're assuming your timer is waiting as long as you tell it to
which in my experience is never true especially with time spans this short
the point is to verify it
how is this not verifying it
if the loop runs for too long
and the timer is delayed somehow
becuase you aren't comparing it with another timing mechanism
sigh
???
i have a clock on my computer
i'm comparing it to that
hell yeah, so much more accurate!
1 / 50 s is 20 ms by the way
i trust the stopwatch more than the timer
then you just don't know how these things work
like period
you said you don't know how benchmarkdotnet actually times things so i guess we're in the same boat
strawman
that even gets the benefit of average time, you can't take the average here because jitter is an important metric for game loops
BDN uses
Perfolizer.Horology.IClock
and gets a completely custom clock depending on the target of the benchmark10 seconds in loop = 10.9501011
so stopwatch is either very wrong or your timer consistently delays longer than intended"my" timer lol
you're defending it ĀÆ\_(ć)_/ĀÆ
i'm just adding this to my list of timers that aren't accurate enough for game loop synchronization
couldn't be that stopwatch is wrong
just impossible
so windows performance counters are off by 50%?
on my system at least it reports stopwatch resolution to be 100ns
which should be more than enough for this test
practically every non-busy wait i have tried from timers to sleeps to delays all guarantee a minimum wait time, not an exact time
and when you're having them fire every 10-20ms it adds up fast
in the end it's all hardware dependent
i'm not so much "defending" the timer as i am defending my stance on not using stopwatch to measure anything ever
that has too much overhead, no warming up, no optimization
i mean we can pick something else but i doubt it's off by over 50%
that would be entirely unusable
this is on my work laptop. i'm sure we'd get another different result on my home pc
we got different results between us to begin with
and i'm on my work pc š
i'm saying a third different result
we already have enough results to know something is significantly off
i was just saying man
Was this issue resolved? If so, run
/close
- otherwise I will mark this as stale and this post will be archived until there is new activity.