Re: [pygame] Weird problem

[Shandy Brown <sjbrown@xxxxxxxxx>]

Hi Kai.

I recommend the strategy of having your sprites move X pixels/milisecond,
not X pixels/frame

That way you can change your framerate and the sprites will still behave
the same.

Just pass the milisecond delta to your sprites on each call to update()
and have them calculate their new position based on that delta.

Also, 30 framerates is going to be noticably choppy to most humans.  Go
with something higher, like 60.

sjbrown

On Sat, 14 Oct 2006, Kai Kuehne wrote:

> Hi Farai :-)
>
> On 10/14/06, Farai Aschwanden <fash@xxxxxxxxxx> wrote:
> > I think there are different ways to solve the problem, depending on
> > your project. The most proper way is to have more animation movements
> > to make it looking slower (probably easier when using opengl than
> > pure 2D).
> > If anything starts lagging when moving around you have to optimize
> > it. Some ideas:
> >
> > - Aplhablitting takes longer than w/o
> > - Do you really need a framerate of 30? Many games works also great
> > with a lower framerate
>
> No, but that's the problem I have. I'm currently writing a oldschool space-
> shooter game and some ships have to fly faster then others. When I use
> constant 30 frames I can use maximum 2-3 pixel movements per frame
> to not make the whole thing look ugly. It's not very hard to make something
> slower since I can wait just a few milliseconds and move it, when the
> time is over. But how move something faster (and keep looking it smooth)?
> I have tested a bit with pygame.clock.tick() and the maximum framerate
> and the result was that I can use is max. ~45 frames. When I use more,
> I get a 100% cpu usage (someone maybe reminds the problem).
>
> > - Some precalculated shapes (f.e. rotation) will be blitted faster
> > than bring it to the right size/rotation, etc. Sure, the memory
> > consumation is going up on precalculated and in memory stored images
> > - if you move sprites/images around the screen, then make sure to
> > reblit the background only where its needed
> > - Is there a lot of Python code between two blit steps? Can that one
> > be optimized?
> > - Many people calls the pygame functions (and also other included
> > packages) by its packagename.function_name. If such a routine is
> > called often (thousands of times and more) that way (like a lot of
> > blitting) it can be optimized: In your variable declaration area
> > write: paint = pygame.blit
> > Late on in the code use "paint (image...)" instead of "pygame.blit
> > (image...)". This helps Python not to check all the time if the
> > module/function is present and valid.
>
> Thanks for the tips. This is the way I do it.
>
>
> > Keep in mind that Python is still a scripting language, tough the
> > makers of Pygame made a great job with it!
>
> I din't say its a fault of anyone else other than me. Python is
> great and pygame is that too.
>
>
>
> > Gruss Farai
>
> Gute Nacht
> Kai
>