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

Re: [pygame] speculation: a JIT for Pygame



Hi,

You bring up some good points.

Definitely SDL 1.3 support is the future, and it looks like it might actually come out (but not before duke nukem forever).  The slowest parts of most games are the blitters.  The slowest machines are often the ones with poor or no GPUs.

Speeding up the blitters is probably going to speed up a wide range of games, on a wide range of machines (without GPU support).

The other part of Lennards post was for decreasing the maintenance burden of the blitters, and allowing us to increase the types of blitters(or the supported types of surfaces) more easily.  So avoiding extra dependencies will help with that goal of Lennards.

Definitely going towards opengl, and directx(which pygame already uses sometimes) is a good idea for a large amount of machines.


For most games, using the pygame.sprite classes effectively, and using approriate image types will give pretty good speed ups.  These things can help even with OpenGL, where reducing the amount of data drawn will often speed things up.

cya!



On Mon, Jan 24, 2011 at 4:28 PM, Tom Rothamel <tom@xxxxxxxxxxx> wrote:
Is spending a lot of effort on software blitters the right strategy for pygame? It seems like SDL 1.3 is moving in the direction of API-based rendering, which wouldn't benefit much from new software blitters. I'm not sure it makes sense to make pygame bigger and harder to compile, only to duplicate functionality provided by hardware.

By API-based rendering, I mean things like OpenGL and DirectX, which generally are accelerated by hardware. But you also have renderers like Mesa, which (IIRC) is moving to use LLVM to accelerate blitting, as proposed above.