[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] blitting from-to surface with per-pixel alpha doesn't work...



------ Original Message ------
> > > [D. Gyimesi composites images for his tank because parts rotate
independently in a hierarchy]
> >
> > [Pete shinner suggested using a matrix stack to draw each element at the
right place, once]
> 
> [Matt Bailey suggested nested matrices is overkill]
> 
Matt, you are right, you don't need a transformation stack for having just a
couple jointed 2d items. It is just simple trig.

Döme, 
I assume you are using pygame blits and roto-zoom, if that's the case then I
think Pete's suggestion of drawing each item at it's correct location (rather
than compositing) is easiest to code and would give decent performance
considering the limitations of SDL/Pygame, because it seems you would
potentially be compositing the tank frames once per draw if the tank & turret
keep moving. In your case properly compositing every updatecould be a
performance issue, especially if it was written in python - but then again
custom compositing code is something that could be combined with the rotation
operation (using c++ code like in Anti-grain geometry) so with some work you
could probably get something that would be even faster than pygame's roto-zoom
(because you would rotate & composite into the intermediate frame in one step,
instead of getting a rotated frame then compositing that)

However, if you use pygame blits to draw each part of the tank to the screen
you will probably have some minor graphical glitches. I don't think pygame
blits have subpixel accuracy (where you can render to non-integer positions on
the screen, somebody correct me if I'm wrong), and without subpixel accuracy,
you will get some "sliding" and "popping" of the turrets position relative to
the tank as the tank rotates (as it's position on the tank would round &
truncate it would appear to jump around less than 1 pixel around the tank) -
but that may look totally fine in an action game where the tank & turret can
rotate quickly (would only matter if you rotate slowly, but then the rotation
itself may look crappy)

OpenGL on the other hand can render with sub-pixel accuracy, supports matrix
transformation stacks like Pete mentioned and would be faster for rotation &
alpha blending.

So I figure you probably want to go one of 4 paths:
1. accept the graphical glitches and use pygame blits to draw the tank
elements at their transformed offset of the tank (easiest, somewhat faster
than what you have now)
2. render with opengl and draw the tank elements at their transformed offsets
(more work and less compatible than sw rendering, but definitely the fastest
and will look good)
3. do compositing after roto-zoom in reasonably fast python code (not too
hard, but the slowest option)
4. put together some c++ extension to rotate & composite into the temporary in
one step (best compatibilty because it's sw rendering, hardest to code, faster
than what you have now, and may look the best)

My recommendation would be to try 1 first, and if the popping & sliding is a
problem, to pick the one of the other 3 options that sounds best to you...