and structs can be disposable, see ComPtr
and structs can be disposable, see ComPtr
Myeah fair point
Kyeah which is fair and the question is now how to actually go about this
Mthey can be but since they have no lifetime tracking i hate doing so unless there's a really good reason to
Ktbh half of why i went and made this is i wanted something to progress with this branch
P- do the sleep
- figure out how much we’ve overshot the sleep and return it
- user passes it in for next time, overshoot is subtracted from the sleep duration
- figure out how much we’ve overshot the sleep and return it
- user passes it in for next time, overshoot is subtracted from the sleep duration
Mso you're tracking state via a ref... i do believe you've reinvented classes
Pbut we’re not tracking state?
Kok but how do we figure out how much weve overshot, because the issue that leads to this is that stuff outside Sleep() is also taking time
Kmy half implementation doesnt even compile since its a readonly struct lol
Myou have a variable that is passed to the method and then returned from the method to be passed again for the next call
Pahhhhh, good point
Pyeah, 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.