You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently (I am on 3.0.0.dev36, but I see it still in master, delta_time is multiplied by 60 and there is a motivation:
# NOTE: change_x and change_y (or velocity) are historically defined as
# the change in position per frame. To convert to change in position per
# second, we multiply by 60 (frames per second).
# Users can define these values in any unit they want, but this breaks
# compatibility with physics engines. Consider changing this in the future.
delta_time *= 60
I would like this factor of 60 to be dropped so that e.g. speeds and similar can be defined in time units of seconds rather than frames.
I have been using arcade since major version 2, and there used to be one method update with fixed delta_time and one method on_update which took it as an argument, and I believe the docs encouraged use of on_update, so I did that. It became perfectly natural to define all speed etc with a time unit of second rather than a time unit of 1/60 second (otherwise I would have had to throw in an extra factor of 60 in every on_update). Now it seems like update and on_update have been merged into just update, with delta_time. I agree with just having one update method (and I am sure there was a reason for choosing the name update over on_update), but the choice of having this factor 60 means that user who used on_update (like me) run into problems. It also means that new users of arcade must use 1/60 s as the unit of time. It all seems very counter-intuitive and strange. There is a reference to "physics engines" breaking if this is changed, but I am not sure which physics engines are referred to (if it was just referring to physics engines in arcade, it should all be fixable?).
I am making this request to throw my vote in for dropping the factor of 60.
What would it help with?
I am currently handling this by overriding update with a fixed (no factor of 60) version. If I don't do this, I would have to divide all my speeds by 60 and all my accelerations by 60^2. I could do this, but using 1/60 s as the unit of time feels counter-intuitive. I also believe this is an extra complication for new users (unless 1/60 s is somehow a common unit of time in games? What does e.g. pygame do?)
The text was updated successfully, but these errors were encountered:
That is the goal in the long run, but not in 3.0. We still have to obey velocity being in "pixels per frame at a framerate of 60" due many factors. If you want to change this default just override the update() method. Assigning this to 3.1 and we'll see where things go. There is a lot of physics stuff that needs to be resolved here we well. Work in that will start soon.
Ok, that's fine by me. (Though I worry that it sounds like a mild breaking change between 3.0 and 3.1 which might affect new users, so unless 3.1 comes quickly, there may be a need for some documentation or warnings. But I leave that to you.)
Enhancement request:
What should be added/changed?
Currently (I am on 3.0.0.dev36, but I see it still in master,
delta_time
is multiplied by 60 and there is a motivation:I would like this factor of 60 to be dropped so that e.g. speeds and similar can be defined in time units of seconds rather than frames.
I have been using arcade since major version 2, and there used to be one method
update
with fixeddelta_time
and one methodon_update
which took it as an argument, and I believe the docs encouraged use ofon_update
, so I did that. It became perfectly natural to define all speed etc with a time unit of second rather than a time unit of 1/60 second (otherwise I would have had to throw in an extra factor of 60 in everyon_update
). Now it seems likeupdate
andon_update
have been merged into justupdate
, withdelta_time
. I agree with just having one update method (and I am sure there was a reason for choosing the nameupdate
overon_update
), but the choice of having this factor 60 means that user who usedon_update
(like me) run into problems. It also means that new users of arcade must use 1/60 s as the unit of time. It all seems very counter-intuitive and strange. There is a reference to "physics engines" breaking if this is changed, but I am not sure which physics engines are referred to (if it was just referring to physics engines in arcade, it should all be fixable?).I am making this request to throw my vote in for dropping the factor of 60.
What would it help with?
I am currently handling this by overriding
update
with a fixed (no factor of 60) version. If I don't do this, I would have to divide all my speeds by 60 and all my accelerations by 60^2. I could do this, but using 1/60 s as the unit of time feels counter-intuitive. I also believe this is an extra complication for new users (unless 1/60 s is somehow a common unit of time in games? What does e.g. pygame do?)The text was updated successfully, but these errors were encountered: