[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:
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