title: Frame-independent movement issue in PyGame with Rect class
body: <p>I'm writing a simple game with PyGame, and I've run into a problem getting things moving properly. I'm not experienced with game programming, so I'm not sure if my approach is even correct..</p>
  
  <p>I have a class Ball, which extends PyGame's Sprite class. Each frame, the Ball object is supposed to move around the screen. I'm using frame-independent(?)/time-based movement with the time delta returned by PyGame's Clock object each time around. Such as,</p>
  
  <pre><code>class Ball(pygame.sprite.Sprite):
     # . . .
     def update(self, delta):
         self.rect.x += delta * self.speed  # speed is pixels per second
         self.rect.y += delta * self.speed  # ... or supposed to be, anyway
  </code></pre>
  
  <p>... and ...</p>
  
  <pre><code>class Game(object):
      # . . .
      def play(self):
          self.clock = pygame.time.Clock()
          while not self.done:
              delta = self.clock.tick(self.fps) / 1000.0  # time is seconds
              self.ball.update(delta)
  </code></pre>
  
  <p>PyGame's Sprite class is backed by a Rect object (rect) that tracks the sprite's position. And Rect's coordinates are automatically converted to integers whenever a value is updated. So, my problem is that each time update() is called, any extra fraction-of-a-pixel movement is lost, instead of being accumulated over time as it should. Speed in "pixels per second" isn't accurate this way. Even worse, if the amount of movement per frame is less than one pixel, the ball doesn't move at all for those frames, because it's always rounded down to zero. (i.e., no movement if pps &lt; fps)</p>
  
  <p>I'm not sure how to deal with this. I tried adding separate x and y values to Ball which aren't forced to be integers and updating the rect every time those change. That way the x and y values accumulate the fractions of a pixel as normal. As in,</p>
  
  <pre><code>class Ball(pygame.sprite.Sprite):
      #  . . .
      def update(self, delta):
          self.x += delta * self.speed
          self.y += delta * self.speed
      def getx(self):
          return self._x
      def setx(self, val):
          self._x = val      # this can be a float
          self.rect.x = val  # this is converted to int
      def gety(self):
          return self._y
      def sety(self, val):
          self._y = val      # this can be a float
          self.rect.y = val  # this is converted to int
      x = property(getx,setx)
      y = property(gety,sety)
  </code></pre>
  
  <p>But that ends up being messy: it's easy to update the rect object when x and y change, but not the other way around. Not to mention the Rect object has lots of other useful coordinates that can be manipulated (like centerx, top, bottomleft, etc. -- which is why one would still want to move the rect directly). I'd more or less end up having to re-implement the whole Rect class in Ball, to store floats before it passes them down to the rect object, or else do everything based on just x and y, sacrificing some of the convenience of the Rect class either way. </p>
  
  <p>Is there a smarter way to handle this?</p>