Hi, note there is a new Surface.scroll method Lenard added to pygame 1.9.0
http://pygame.org/docs/ref/surface.html#Surface.scroll There's an example too... python -m pygame.examples.scroll Which would be useful for some purposes... but surfaces are still limited to a certain size... so maybe not perfect for your option. cheers, On Mon, Aug 3, 2009 at 8:31 PM, Ian Mallett <geometr...@gmail.com> wrote: > Hi, > > There are several "fixes" for speed, but they aren't pretty. > > The simplest is to use a smaller "large surface". If you still need the > same "size", you can use a smaller surface and simply scale the sampled > surface up to fit the screen, which in itself is fairly quick. Even if you > cut the original surface in half, you cut the area by 4. If you use > smoothscale, you could probably get away with a 4x or 6x reduction, which > should be plenty speedup for the game. If the surface contains only > thick-ish lines aligned along axes, huge reductions are possible. I used > this technique with 100x reductions for great gain at no visual cost. > > If scrolling is relatively infrequent, you can make a surface from the part > of the large surface that is on the screen and cache it. > > Another idea is to split the updates over several frames. For example, > update the left half and the right half of the screen alternately. Will > McGugan showed that similar updating methods can be effective in > "sidescrolling games" in his book. > > You can combine split updates and scrolling too. Use a cached surface for > the background. If you're scrolling, the first frame, create a surface "A" > the same size as the screen, and blit half of the required sample from the > large texture onto it. The second frame, blit the other half of the > required sample onto the surface "A" and use it to update the cached > surface, and hence the background. > > Another idea is to break the large surface up into little surfaces (e.g., > break a 13000x13000 surface into 169 (13 in each direction) 1000x1000 > surfaces), and only draw those little surfaces that are on screen. This > avoids the sampling-from-a-large-texture-bottleneck. In the worst case > here, like you have a 800x600 screen, and four little textures are on > screen, sampling occurs from effectively 4*1000*1000 = 4,000,000 texels > instead of 1*13000*13000 = 169,000,000 texels. It's a bit more complicated > than that, but that's the general idea. > > Another solution is simply to use OpenGL--which is what I ended up doing > several times--although that's probably not what you want at all. > > Ian >
