Re: [pygame] Back to the Scrolling

[Pete Shinners <pete@shinners.org>]

Phil Hassey wrote:
> 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.

yeah, the implementation of "tilerow" is about as high level as i'd want 
to take it. at this point it should still be usable in a majority of 
scrolling algorithms, but it just doesn't seem to be where the speed 
problem is.

it seems to come back to the one problem i've had trying to optimize 
"batch" drawing methods in C. by the time you've spent translating your 
python data structures into a list of drawing primitives, you've spent 
just as much time as doing the rendering straight in python.

i've tried to come up with faster ways to draw big groups of primitives 
(for example, particles), or blit many images, but they never end up 
with a speed advantage. i'm thinking the only hope for success for any 
sort of "speed up in C" is to create your datatypes as real C objects 
and add bindings for them to python. then the C code can do all the work 
natively. otherwise it won't buy you any speedup, but that is such a big 
task that i don't think it's worth it. perhaps something like pyrex then 
would be the best way to go.

the other option is to just use a hardware accelerated display from SDL, 
then the bottleneck moves from blitting speed to python code, which is a 
good thing!


____________________________________
pygame mailing list
pygame-users@seul.org
http://pygame.seul.org