if youre disconnecting from a sequence of timestamps then this should take the sleep duration as a p
if youre disconnecting from a sequence of timestamps then this should take the sleep duration as a parameter and lose the inherent periodicity
Kand then do as Maxine suggests and have a wrapper type to handle the timestamp part or just do that in the window implementation
Mthat would get it a lot closer to what its name implies
Kid rather have the loop rate limiting aspect be separated so it can be used in other code too but theres no real reason to prefer that
Munrelated; the OS and architecture checks not being guarded in if-else if feels weird to me, is there a particular reason for that
Ldoes it matter
Mdoes what matter
PI guess the main thing is the use case of this breakneck type is quite complicated. It needs to sleep for 1/UpdatesPerSecond, 1/FramesPerSecond, or 1/MaxThrottle, and needs to be able to resume sleeping for the next event. e.g. if we resume for render but update is not due yet, then we just need to sleep for the remaining time until update is due or the max throttle (whichever is smaller)
Lit not being
elsethis is perhaps where the current design breaks down given that duration is not configurable
Mfrom a readability perspective it would help to understand that none of these if blocks can be entered at the same time at runtime and it would also help if that had to be changed in the future
Pso perhaps duration also needs to be a parameter rather than a configuration option, which thinking about it makes more sense.
Mbut i know it's a nitpick i was just curious if it was on purpose
PI mean really all of this out of scope of this type, this is basically just a wrapper over a sleep function, so really it needs to sleep for TimeSpan and maybe return how long we actually slept for. Any further time tracking is out of scope of this type.
Pand would instead be in scope for a proper FrameLimiter type that does track this state
Kid call it LoopRateLimiter since its more than frame limits, also update or just general throttling
Kbut yeah
Kadjusted BreakneckSleep to take a duration parameter and pushed
Pwe can bikeshed the name a bit later on, I’m not 100% on Loop being in the name and just RateLimiter is ambiguous and/or misleading
Kyeah
Mmake it work first figure out the name later
Kin any case its 1am for me so i aint doing the actual limiter part now, but breaknecksleep now takes a duration like any self-respecting sleep function should
K"nit: I would like there to be one more space"
+ GitHub suggestions field makes everything good
+ GitHub suggestions field makes everything good
Psure but if that’s the only comment I can come up with I just ignore it.
Papologies for not working on silk, this cold is killing me
Lim still recovering from Sick too
Khope it passes soon
Land now SCHOOL is starting in 1 hour
Lpain.
Kwhoops, turns out my pr from last night doesnt build still because i didnt have the lab sample thing in my .gen.sln and didnt notice it needed changing
Kfixed that now
Kdont think im up to actually do the framelimiter part anytime soon, life kinda hell rn and i cant focus, but got this done at least
Pexperimented with TimeWindow (which uses BreakneckSleep):
Pquite all over the place
P0.035 is ~29 FPS and 0.015 is ~66 FPS
Psaying that though, without no sleep at all it's very similar, so there may be some issue with how TimeWindow is implemented
P
Pi'll hand this over to the community to scrutinise further, this is far too intricate for too little for me to care anymore
POH I'M AN IDIOT
Pi still have the old spinny code in windowing
PWith BreakneckSleep
PWithout BreakneckSleep
PCPU usage peaked around 20% on my laptop without BreakneckSleep
PCPU usage peaked around 30% on my laptop with BreakneckSleep
Pyeah I seriously don't know anymore
Punless anyone can figure out how to make BreakneckSleep/TimeWindow work, let's not ship anything here and just stick with our busy loop
Pdoing updates on the GitHub Runner, don't do anything for a sec please
Pauto merge mugged me off there
Pshould be good now
KOk so this is the kind of problem I like
Pwhat were we waiting for for 2.18 again
