Files changed (2)
+ * ``pygame.display.update()`` -- This updates the whole window (or the whole screen for fullscreen displays).
+ * ``pygame.display.flip()`` -- This does the same thing, and will also do the right thing if you're using ``doublebuffered`` hardware acceleration, which you're not, so on to...
+ * ``pygame.display.update(a rectangle or some list of rectangles)`` -- This updates just the rectangular areas of the screen you specify.
+ * It only works on some platforms. Windows machines can usually get hardware surfaces if you ask for them. Most other platforms can't. Linux, for example, may be able to provide a hardware surface if X4 is installed, if DGA2 is working properly, and if the moons are aligned correctly. If a hardware surface is unavailable, SDL will silently give you a software surface instead.
+ * It complicates per-pixel access. If you have a hardware surface, you need to Lock the surface before writing or reading individual pixel values on it. If you don't, Bad Things Happen. Then you need to quickly Unlock the surface again, before the OS gets all confused and starts to panic. Most of this process is automated for you in pygame, but it's something else to take into account.
+ * You lose the mouse pointer. If you specify ``HWSURFACE`` (and actually get it), your pointer will usually just vanish (or worse, hang around in a half-there, half-not flickery state). You'll need to create a sprite to act as a manual mouse pointer, and you'll need to worry about pointer acceleration and sensitivity. What a pain.
+ * It might be slower anyway. Many drivers are not accelerated for the types of drawing that we do, and since everything has to be blitted across the video bus (unless you can cram your source surface into video memory as well), it might end up being slower than software access anyway.
+So you've got your sprites moving around, and you need to know whether or not they're bumping into one another. It's tempting to write something like the following:
+ * For each pixel in the overlapping area, see if the corresponding pixels from both sprites are opaque. If so, there's a collision.
+There's a lot of confusion around these two techniques, and much of it comes from the terminology used.