day #3, a camera

Not a whole lot done tonight other than playing for an hour with a camera for some scrolling. I'm a little unsure of a good way to go about it actually, since the x and y properties of pyglet sprites are expressed in window coordinates. When the player presses a key they change the sprite's world coordinates in absolute terms, but to make the camera work then the world coordinates of all the sprites need to be translated to the window coordinates. However, without keeping track of world and window coordinates separately, it seems I need to reverse translate the sprite's x and y at the beginning of the next update back to world coordinates, before applying another transformation to window coordintes. If that makes any sense. It seems like adding a new pair of properties for world xy could be a good choice.

(log in to comment)


You could have a camera class that sets a MODELVIEW transformation depending on the camera's position. I wrote about doing this in 2D here:
slides 6 to 10
If you go to the parent directory, then the demo source code is there too.
(the wrinkle is, where I talk about setting the PROJECTION matrix at the start of the camera function, ie at the start of every frame, you don't need to do that part - you should just set it on a resize handler instead)

So the basic outline would be:

create camera as outlined above

def on_resize:

    set PROJECTION as described above

def on_draw:
    set camera MODELVIEW (as described in the above presentation)
    for ent in game_entities:
        push MODELVIEW
        glRotate ent.angle # optional
        glScale ent.size # optional
        glTranslate ent.x, ent.y
        draw ent (eg. sprite.draw or whatevever)
        pop MODELVIEW

Then you can scroll the camera around by setting camera.x and camera.y

I hope the formatting comes out ok. :-)
Very interesting tartley, thank you! I had thought about doing the translation with OpenGL but wasn't sure if that would be a black hole timewise, that slideshow is a great introduction.
Yeah, your worry seems pertinent - if it isn't something one has all figured out ahead of time, I wonder if it might go pear-shaped and burn up too much time. I decided to steer clear of it for this pyweek, and just get something very simple out the door.