Re: [Pysdl-devel] Announce: pyAliens 1.0

[Mark B. <mb...@0x...>]

On Thu, 08 Jun 2000, "David Clark wrote:
> > Does the speed limitation of the Python
> > interpreter mean that it runs at somewhat similar
> > speed on different-speed cpus?
> 
> My guess about the source of the speed limitation is apparently
> incorrect. Running on the same system using HWSURFACE vs. SWSURFACE
> results in a huge speed difference, as you comment. Thus, the
> limitation in speed is due to SDL and/or pySDL. I suspect it's due to
> SDL, since running the C version of aliens without the frame rate
> limiter results in a similar jump when going from software to video
> memory.

I'd blame all three at least a little. ;-)
The PySDL version is quite a bit slower than the C version, however. I'm apt to
blame Python for this, but with SVGAlib, it's still quite speedy.
You did an excellent job of porting the little game, regardless of the failings
of PySDL and Python.



> Nonetheless, you're right - different systems will play my pyAliens at
> vastly different speeds. The reason is simple. Sam's aliens is speed
> limited - it can never get above 50 fps, no matter how fast your
> computer is. This is The Right Thing. I chose not to port that section
> of code ( wait_frame() for anyone who wants to write a patch ),
> partially because I wanted to see how performance varied over
> different systems and different video flags, but mostly because I
> didn't want to bother learning Python timing techniques last
> night. You see, SDL has a timing-specific subsystem, but Mark has
> decided (rightly, IMO) not to incorporate that subsystem into pySDL,
> instead leaving timing issues up to the python library. I may write
> the appropriate code tonight; we'll see how motivated I am.

I don't mean to belittle Sam Lantinga, but his approach is also flawed, and I
imagine he only did it for simplicity. Certainly for this sort of game it
doesn't matter, but when designing games, you shouldn't attempt to frame lock,
for any number of good reasons.  A superior approach is to work in terms of
delta t. Each portion of game logic takes a certain amount of time, and the
functions used to implement them should work in terms of this.
Each time your heart beat pulses, you should update your game state using the
amount of time that has passed. You move your sprites whatever percentage
they've gone, you increase velocities whatever percentage they've accelerated,
etc.