yeah, what part of that is us [BreakneckSleep] tracking state
yeah, what part of that is us [BreakneckSleep] tracking state
Kan idea then:
- return GetTimeStamp() and take the last timestamp as a parameter
- return GetTimeStamp() and take the last timestamp as a parameter
Kinstead of passing around TimeSpans
Myou're moving that responsibility to the caller but by having that parameter at all you're getting most of the theoretical drawbacks of using a class
Mso i reckon a class is the occam's razor thing to do here
Pyes, with the breakneck types literally any and all responsibility falls on the user
Pthey’re designed to do whatever the user wants them to do and to do it without any overhead
Pand for this reason I encourage most users to stay away from them
Plike no one should use BreakneckLock it’s outright dangerous
Kthis is implementation detail type stuff generally
Mi'm not recommending a class to make it easier to use as much as to avoid overcomplicating the type's design
Pcan return the last timestamp, but I am hesitant to have the parameter be the timestamp as this implies the previous sleep and the next sleep are related which they may not be in every case.
Kif we did go that direction id suggest renaming to something like
LoopRateLimiter to not associate with Breakneck, or split that out into a seperate class and keep the native stuff seperate in BreakneckSleepKtrue but at that point why have the duration property at all?
P…fair point.
Kif 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
elsePthis 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
