[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