OK, Frank has been waxing eloquent on how difficult it is to get fast
and consistent updates in a game. Various methods may be tried:
1. Use a timer with a very short period
2. Use an update loop in a thread
3. Use an update loop not in a thread
But they each have their drawbacks. (Note that option 3 implies
using #pragma disableBackgroundTasks, and option 2 implies not using
it, unless there's something I'm not thinking of at the moment.)
Here's what I propose: let's make a simple demo/benchmark app that
lets us experiment with these (and other?) techniques. It should
contain an Rb3DSpace, and a long Canvas. The Rb3DSpace should show
some object and perhaps spin it around a bit on each update.
The canvas will make a graph, with time running along the bottom, and
interframe interval plotted on the Y axis. On each frame, you
advance your XPos in the canvas by one pixel, draw a white line at
that position (to erase the previous blip), and then draw a pixel at
XPos, YPos where YPos is calculated from the time measured since the
last frame. Of course when XPos = canvas.width, reset it to 0.
Now, we can try out various ways of updating this thing, and both see
how fast it is, and how consistent it is. Ideal would be small frame
times, and very consistent (so the line is pretty flat). If it's
jumping around randomly, or periodically hesitates, we should see
that clearly in the graph.
Any volunteers for this project? (I'm sure others will pitch in once
the basic framework is set up, but somebody has to do the first
draft.)
Cheers,
- Joe
--
,------------------------------------------------------------------.
| Joseph J. Strout REAL Software, Inc. |
| joe at realsoftware dot com http://www.realsoftware.com |
`------------------------------------------------------------------'
---
A searchable archive of this list is available at:
<http://support.realsoftware.com/listarchives/search.php>
Unsubscribe or switch delivery mode:
<http://support.realsoftware.com/listmanager/>
.
|