I took the frame controller methods used in the benchmark straight from
my SuperSpriteSurface and 3d framework. Threads and tight loops are
very fast there, so I would suggest in addition to testing different
frame controller methods that you test the different graphics surfaces
such as raw OpenGL to try and find the bottleneck.
John
On Wednesday, July 23, 2003, at 02:16 AM, nickdabner at optusnet dot com dot au
wrote:
I thought as much. Sounds like some additional #pragmas may assist to
control
RB behaviour in this manner. Certainly something non-malicious such as
"ignore
mouse events" or "optimisefortightloop" where the specific needs could
be
supported.
Any idea if it would be possible to ignore backgroundtasks, but yield
or SMP other
RB threads? Pigs might fly? Unsure of how things work when you get
that low in
the system.
regards,
Nick
Frank C <pox at planetquake dot com> wrote:
I haven't done a controlled comparison, but a tight loop in RB is
just
about as fast as a tight loop in C (using immediate mode OpenGL at
least). Where things start to go off is when you introduce an event
loop - in C you have total control, so you can pick and chose what to
deal with and what to ignore, and how often to yield to background
tasks. In RB, you're a slave to the runtime.
Frank.
---
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/>
---
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/>
.
|