If you are using rabbyt, I assume you are using opengl, and if so then
speed shouldn't be an issue. However, texture sizes in opengl are more
limited than surface sizes in pygame, so you'll need to use smaller
tiles (like 1024x1024 max). These could of course just load
dynamically from a much larger source image if desired.
I would recommend googling for an opengl based scrolling solution in
python, someone's bound to have done it before, though it likely
wouldn't be too hard to do yourself.
-Casey
On Aug 3, 2009, at 12:30 PM, Yanom Mobis wrote:
well i need it to work with a BIG surface.... at 30 fps. and i need
something that would work with Rabbyt
From: Casey Duncan <ca...@pandora.com>
To: pygame-users@seul.org
Sent: Monday, August 3, 2009 12:51:32 PM
Subject: Re: [pygame] Scrolling
You can blit a surface that is bigger than the pygame screen and it
should efficiently crop it for you without extra work on your part.
At some point though you will probably run into surface size
limitations, in which case you can just tile surfaces together.
In my experience with pygame, full screen blitting is really only
fast enough at fairly low resolutions. But of course YMMV.
-Casey
On Aug 3, 2009, at 11:32 AM, Yanom Mobis wrote:
> How is scrolling done in pygame? i was thinking of blitting all
gameobjects to a surface, then blitting part of that surface to the
screen like this:
> +---------------------+
> | +-------+ |
> | | | |
> | +-------+ |
> | |
> +---------------------+
> where the big box is the surface, and the small box is the screen.
>
>
