[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [pygame] Back to the Scrolling


> everyone feel free to send in ideas on how this could be improved a bit.
> if there's a nice general way to get rid of the python overhead in
> scrolling, i'm all for it. the big performance problem with full
> scrolling is really copying all that memory around, and SDL makes it
> happen twice internally, ugh.

I suggest not adding any scrolling specific code to Pygame.  It seems that 
there are so many different kinds of scrolling -- with different cases, that 
many different game engines would have very different needs from a scrolling 
engine.  (For example, some have two or three layers of independantly moving 
backgrounds, others have two or three layers of backgrounds that move 
together.  Then some have foregrounds.  And sprites have to fit into it all 
to, and depending on what kind of scrolling, the sprites can be optimized 
into it all in a number of different ways...)  Beyond all that, there are 
different algorithms (sort of) for doing different things, depending on 
special cases.  Like if certain blocks or sprites can be assumed to have no 

One idea I had a while ago for making it possible to eliminate the python 
overhead in scrolling / other tight loops is by using pyrex.  
Pyrex generates C modules from "python-like" code that includes special 
keywords for doing C-stuff.

To really be able to use pyrex for pygame, I think pyrex would have to be 
extended to be able to include header files.  (I believe this is planned...  
Right now header files have to be redefined within your pyrex files.)  Then 
scrolling (or whatever) could #include "pygame.h" and "SDL.h" and do 
PySurface_AsSurface conversions on pygame objects.  The code would then be 
freed up to use SDL directly.  Although until pyrex can include header files, 
the following gets the basics done...

cdef extern from "SDL.h":
    cdef struct SDL_Surface:
        char *pixels
        int pitch

cdef extern from "pygame.h":
    SDL_Surface *PySurface_AsSurface(object s)

Then you can cast python objects to SDL surfaces, and do your blitting and 
other stuff without the overhead of python.  (Currently, for each SDL 
function you want to use you need to define it within the pyrex file, 
however.  The code listed above I used for generating a mandelbrot, so I only 
needed access to the surface pixel data.  Everything else I used 
python/pygame for.)  The resulting C code was (I think) about 20 or 40 times 
faster than the python version.  I don't expect the speed up would be as 
impressive for a scrolling engine, but I suspect it would help.

Anyway, for a conclusion.  My reason for suggesting pyrex for this problem is 
that I don't think a built in scrolling engine would cover many of the 
different kinds of scrolling engine needs that exist. On the other hand, 
maybe a simple one would meet enough peoples needs that it would be useful.  


pygame mailing list