New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Breaking changes to frame time APIs (if any) #1847
Comments
I don't know if detla_time should be changed away from being a float. Arcade is supposed to be beginner friendly, so leaving it as a float is for them. |
I left a detailed comment on an implimentation idea in issue #1795. I think arcade should provide its own clock so we can get it working exactly how we want it. Though this could certainly be a 3.1 implementation. Secondly, all this time stuff has made me want to look into a fixed update method for arcade. Not like having a fixed dt, but rather a "catch-up" method that will call enough times that the simulated time equals the time passed. It's vital for good quality physics. |
I agree about that. However, I am still split about arcade having its own clock. |
The API changes for 3.0, precursor to future enhancements to time handling:
For any |
Note to self: capture summary of conversation started here: https://discord.com/channels/458662222697070613/458662458198982676/1145119205771976724 |
From @einarf's 3.0 wishlist:
To limit scope of 3.0, let's focus on breaking API changes if any. But it requires a broader conversation about our time APIs.
Q: What breaking changes -- if any -- can we make in 3.0 to enable improved time APIs in the future?
Right now, most
update
andon_update
functions accept a floatdelta_time
.Should they accept a richer time object? <-- breaking
Should we add a time object to
Window
? <-- not breakingPast discussions:
#1795
#1543
https://discord.com/channels/458662222697070613/1110676843763335200
The text was updated successfully, but these errors were encountered: