2

I'm currently making a 2D side-scrolling run'n'jump platform game in PyGame. Most of the stuff is working OK and very well in fact - I am exploiting the fast pyGame Sprite objects & groups.

What I'm interested to know is how people usually deal with Rects for scrolling games. I obviously have a level that is much bigger than visible area, and the player, enemies, bullets etc each have their own (x,y) coordinates which describe where they are in the level.

But now, since we use the "spriteGroup.draw(surface)" call, it will not display them in the right spot unless each objects Rects have been adjusted so that the right part displays on the screen. In other words, everytime a player/enemy/bullet/whatever else is updated, the Camera information needs to be passed, so that their Rect can be updated.

Is this the best method to use? It works but I don't really like passing the camera information to every single object at every update to offset the Rects.

Obviously the ideal method (I think) is to use Rects with "real" coordinates, blit everything to a buffer as big as the level, and then just blit the visible part to the screen, but in practice that slows the game down A LOT.

Any comments/insight would be appreciated.

Thanks

leppie
  • 115,091
  • 17
  • 196
  • 297
RedCap
  • 61
  • 1
  • 3
  • I've never used Pygame but I assume you can use a translation matrix to keep everything in "real" coordinates without having to create a buffer as huge as the level. – Doggett Nov 01 '10 at 23:41
  • Well not really, that's the point. Pygame lets you draw many sprites at one time but doesn't let you transform their coordinates too. – RedCap Nov 02 '10 at 02:30
  • possible duplicate of [Add scrolling to a platformer in pygame](http://stackoverflow.com/questions/14354171/add-scrolling-to-a-platformer-in-pygame) – sloth Sep 11 '15 at 07:33

5 Answers5

1

You could extend de Sprite.Group so it recives the camera information. Then do one of these options: A. Override the update method so it updates the on-screen coordinates of every sprite. B. Override the draw method so it updates the on-screen coordinates of every sprite and then calls its parent draw method.

I think A it's easier and cleaner.

pmoleri
  • 4,238
  • 1
  • 15
  • 25
0

One method I found is to keep track of a scrollx and a scrolly. Then, just add scrollx and scroll y to the coordinates when you move the rectangles.

Chachmu
  • 7,725
  • 6
  • 30
  • 35
0

You can have a 2 variables level_landlevel_d which see where you are in the level, Then check which sprites are in the visible area
level_d+height and level_l+width,
and draw them on the screen.

pradyunsg
  • 18,287
  • 11
  • 43
  • 96
0

The simple way to do it is like that:

Create a CameraX and CameraY variables, and when you blit objects on the screen use this:

blit(surface, (x -CameraX, y -CameraY))

any object that gets affected by the camera should be drawn like that, but keep in mind that there are objects that you may want to remain uneffected (like health bars or status windows)

just keep in mind everytime you want to move camera do this

#Move Camera Right
CameraX += 10
#Move Camera Left
CameraX -= 10
#Move Camera Down
CameraY += 10
#Move Camera Up
CameraY -= 10

Just keep in mind that if they get negative values they may not work correctly, also you must probably define some limits (you dont want your camera to move over the limits of your map

TomTsagk
  • 1,474
  • 9
  • 23
0

I don't really like passing the camera information to every single object at every update to offset the Rects.

Camera may be global, or, a member of a global Game() class instance. Then your sprite class's draw method doesn't need an argument.

You can override draw yourself, so it does:

dest = game.camera.topleft + self.rect.topleft
screen.blit( self.surface, dest )

This keeps the bullet's rect in world-coordinates, yet blits using screen-coordinates.

ninMonkey
  • 7,211
  • 8
  • 37
  • 66