I think I understand what you are saying, if I go with the
fixed-time-steps method: I remove all 'delta's from my math, and I
save alot of headaches. I instead call the physics update() more or
less depending on the framerate?
I need some clarification on the pseudo code:
I put a couple of questi
I made sure they were floats.
The new program is Asteroids 7.1 on pygame.org
I think the solution was mostly successful.
Ian
Ian Mallett wrote:
((0.0075/(IdealFPS**2))*((IdealFPS/TargetFPS)**2))*(TargetFPS**2)
...doesn't work.
Be careful with data types and division. If IdealFPS and
TargetFPS are integers and you're not using future division,
then (IdealFPS/TargetFPS) will be doing integer division.
--
Greg
Yeah, fixed-time physics is the way to go. How you get that fixed time is
up to you, but it's a much better way than trying to put time into all of
your code. It is more stable, and easier to program as well. Since you are
thinking about lower end computers, you may have to rebalance everything
I think the best option is to call the update etc. functions the correct
number of times. The thrust still seems a little off--slightly slower at
slower framerates.
My high-level advice is that the approach you are trying to use to achieving
frame-rate independence is a math heavy and complex path to getting right,
and the issue you are seeing here is just the first of many like it (and
some worse). There is a much simpler approach, where all your simulation
u
Jake, that is actually pretty much my current solution. :)
I just noticed that linear things, like turning speed do seem to scale
properly. Acceleration things, as indeed thrust is, don't.
((0.0075/(IdealFPS**2))*((IdealFPS/TargetFPS)**2))*(TargetFPS**2)
...doesn't work. (Remember, IdealFPS = 198
You can define movement speed per second. That way every computer
moves X pixels/sec ( and faster computers still get the benefit of
more FPS )
Ie: velocity = 10 pixels/sec , or rotation = 90degrees/sec
Then calculate how much to move based on the users FPS:
# fps.py
class FPS():
def __i
I usually either use time directly in my calculations (rather than fps),
because I find it more natural. Does the velocity depend linearly on
thrust, or is thrust an acceleration? If the units on thrust are
something like meters per tick squared, then I think you will need to
compensate twice
Hello,
I have a game, written in pygame, but it now needs to support more
framerates.
The movements of objects need to be at the same speed, regardless of the
framerate.
Here is an old line:
self.thrust = 0.0075
Here is the new line. The game was developed on my computer at 198 fps
(IdealFPS), b
10 matches
Mail list logo
