[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [pygame] Timing...



Michael Robin wrote:

> When the # of objs is on a cusp, it's very obvious from looking at the
> objects
> move that some loops have to wait for a refresh, and some don't - causing
> jerky movement.

Not sure what you mean by "cusps", but looking at your table they seem to be
the inflection points of your NumObjs-FPS curve.  The same kind of thing is
going to happen with any game.  (Actually it's a common economic phenomenon.)

> Currently w/o C extensions, I need the speedup (about 2-4x) that
> DOUBLEBUF|FULLSCREEN and directx give me.
> Any way to avoid this effect? (I assume not- kind of the nature of the
> beast.)

I've had some success eliminating this kind of problem in DirectX (that's
straight C++/DirectX, with no pygame or SDL) by adding a
DirectDraw->WaitForVerticalBlank() call.  It costs a few fps but it can make
drawing go much more smoothly.  (Not always, though.)  Unfortunately I don't
think pygame/SDL has anything like this since detecting a VBL is a very
platform-dependent thing.

> The only thing I can think of to do is to have the game "gracefully
> de-feature"
> if the user chooses as-fast-as-possbile mode. I could go in a test loop and
> start
> removing non-essential rendered elements until I am over one of the refresh
> cusps.
> (I could (possibly - argh...) do this because I'm vector-based, not BMP
> based.)

If you really need an "accellerated" mode you should probably just skip the
drawing of entire frames.  I have a feature in one of my C++/DirectX games
where if the human player dies, the game will switch into a hyper-fast mode so
any still-living computer players can finish the round at a speed only a
computer could play at.  :-)  I circumvent the display calls, and thousands of
frames of play happen in just a few seconds.  (The screen does get updated once
a second to let the human player keep up to date on the unfolding action.)  Of
course you don't have to go that far; skipping every other frame might work
well enough and still be playable.

Also, you could try implementing a timing system and running your
"as-fast-as-possible" mode with a very small delay.  Bombarding the system
(i.e. no delay at all) sometimes makes it buckle.  I remember one time I was
running something with DirectX fixed at 60 fps.  I wanted to see just how fast
it could go so I disabled the timing and it slowed down hideously to around 3
fps!  I added a small delay, and that brought it back up to 150+ fps.  (Of
course this could have been rhe result of a flaw in my design, and I suppose it
could also have been a Windows thing.)

Failing all of this you'll probably have to settle for running somewhere
between your two "cusps".  100 objects is quite a lot, and so is 26fps
actually.  Pick a fps rate and then make sure you always maintain it.

-- 
======================================================================
Paul Sidorsky                                          Calgary, Canada
paulsid@home.com                      http://members.home.net/paulsid/
____________________________________
pygame mailing list
pygame-users@seul.org
http://pygame.seul.org