At 10:09 AM -0700 6/27/05, Lo Saeteurn wrote:
That sounds like the best avenue to pursue. I can't think of any
reason why RebuildObject3D should be called for a NavNode in the
game, and if it is, then at the very least, we're doing more work
than we need to be. Perhaps fixing this will render the Quesa
change (whatever it is) irrelevant.
Well that still does not solve the issue of creating new objects. In
a game, all the objects needed to be loaded would be loaded in the
beginning so the wireframe workaround would fix it, but for apps
that loads in new objects during the use of the program may suffer.
You're making assumptions here about what the problem is. I don't
think we have enough evidence to say that.
I hope this is something that the Quesa developers already knows
about. Anyone posted this issue to the Quesa team yet?
No. So far, as far as I know, it's only been reproduced in
Renegades; the Quesa test apps (and several other RB apps people have
discussed here) show 1.7 being substantially *faster* than 1.6d20,
not slower. So, since we already have evidence for a Renegades bug,
I say let's track that down first before we go assuming something is
wrong with Quesa.
Best,
- Joe
--
Joe Strout REAL Software, Inc.
Vote for REALbasic (twice!) in the LinuxWorld Reader's Choice Awards:
http://linux.sys-con.com/general/readerschoice.htm
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
|