On Wednesday, July 23, 2003, at 03:04 PM, Joseph J. Strout wrote:
Well, no, we've discussed how you can choose when to yield to
background tasks. You're just not satisfied with the result,
because when you do yield, it (not surprisingly) causes a glitch in
the framerate.
That's my point! You're yielding on RB's terms.
I'm not sure what that means. You're choosing when to yield. What
more do you want?
I think what he is saying is that in a C program, the programmer is in
full control of the main event loop and can determine which events to
handle, which ones to ignore, and can customize it to maximize game
performance. In RB, you get what the runtime gives you which may not be
optimized for game development. Your options are:
1. Use a timer or thread to update frames and live with the framerate
glitches.
2. Update frames from within a tight loop and lock up the GUI.
3. Disable background tasks and selectively lock up the GUI.
There just doesn't seem to be a happy medium. Somehow, RB game
developers need more control over which events get serviced, how often
they get serviced, and when.
Perhaps this could be fixed through additional compiler directives. Or
maybe we should have an alternate runtime for game development with an
event loop better suited for high framerate games.
Bob
---
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/>
.
|