Cameron
Cameron
#4187 would move these types into a separate crate.
> I'm not sure how I feel about limiting this to only one `FixedTimestep`. I get that this is less error prone, but I'm not sure how it would like...
> A much better solution imho would be to do this automatically and interleave the multiple fixed timesteps automatically. Very roughly, rather than update each fixed timestep until its caught...
> The bpm example may have been a poor example, but it fits for syncing gameplay to music, even if not for coordinating talking to the audio middleware. Ah, okay....
`Time` scaling added by #5752. I'll add `FixedTime` in another PR.
Moving the conversation about this in #5752 back here. I understand its motivation, but putting this "global wrapping period" on `Time` feels like a hack. I don't mean to be...
> I'm not sure why you consider that hacky. I didn't mean in a super negative way. More in the sense of clutter. I think it's "hacky" because `Time` is...
> `seconds_since_startup` should simply be removed as part of this PR; it can be recovered from `time_since_startup` for users who really care, and is effectively just a footgun. This method...
I'm okay with putting it on `Time`, but let me clarify the separate resource idea. You should be able to run a system like this right after the system that...