Path: chuka.playstation.co.uk!news From: Craig Graham Newsgroups: scee.yaroze.programming.3d_graphics,scea.yaroze.programming.3d_graphics Subject: Re: gteMIMefunc Date: Thu, 12 Nov 1998 19:35:31 +0000 Organization: PlayStation Net Yaroze (SCEE) Lines: 27 Message-ID: <364B3883.107B7F6F@hinge.mistral.co.uk> References: <364A002A.62D2@funnytown.com> <364AB794.6D1077CD@scee.sony.co.uk> <364B083F.68AD8B97@hinge.mistral.co.uk> <364B2791.9D438B61@scee.sony.co.uk> NNTP-Posting-Host: d1-s4-36-telehouse.mistral.co.uk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.05 [en] (Win95; I) Xref: chuka.playstation.co.uk scee.yaroze.programming.3d_graphics:1015 scea.yaroze.programming.3d_graphics:326 James Russell wrote: > Why not just use gteMIMEfunc with a variable 'p'? Of course, this means that you have to copy the > original input verts every time, which is less than efficient, but it would mean that you don't lose > the accuracy. But I don't know if this is compatible with RSDAnimlib, which I haven't used before Way to slow (esp. if you want to animate a few large models) - I've got some figures somewherefor the Dino demo's model done both ways (cann't put my hand on them right now). The differance is noticable (shows up easily in the number of Hsyncs the frame takes to setup - could probably get that down with a fast asm memcopy crafted for max thoughput and not caring about a few bytes overrun). RsdANIM only copies the vertices on reset (at the end of a sequence). You could do a block scheme (next version of RsdANIM uses that) and make multiple calls to gteMIMefunc() for a single frame (cuts down on null additions, faster than doing a whole vertex block at one throw when only a subset are moving), as that would reduce the amount of data you reset each time. The method I described earlier works just as well though (better in fact, as it doesn't distort in practise and you don't have to copy the vertex array each frame). > James Craig.