Path: chuka.playstation.co.uk!news From: Craig Graham Newsgroups: scee.yaroze.programming.3d_graphics,scea.yaroze.programming.3d_graphics Subject: Re: gteMIMefunc & me: One of us is wrong Date: Thu, 12 Nov 1998 16:09:35 +0000 Organization: PlayStation Net Yaroze (SCEE) Lines: 44 Message-ID: <364B083F.68AD8B97@hinge.mistral.co.uk> References: <364A002A.62D2@funnytown.com> <364AB794.6D1077CD@scee.sony.co.uk> NNTP-Posting-Host: d2-s16-110-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:1013 scea.yaroze.programming.3d_graphics:324 James Russell wrote: > Gerrit Goossen wrote: > > > > gteMIMefunc(theAnimation->workVertexArray, theData->mimeArray, > > theData->vertexCount, ONE); > > The first argument is both input and output. It is the 'origin' of the vertex, and the second arg is > the difference between the origin and the destination. The function multiplies the difference by the > last arg, divides by ONE and adds it to the origin. To get the desired output, I would copy the > original to a separate buffer before use (D-Cache is fine if it's small enough to fit into 1K). That doesn't sound like it's the reason it's not working though. Here's what RsdANIM does: 1) takes the distance source to dest for all vertices (key to key) (==deltas) 2) multiplies the delta's by ONE 2) divides the delta's by the number of video frames to run over 3) divides the delta's by a small p scaler (starts at one) 4) if any resulting delta's are >32767 or <-32767 then increase p by one and repeat stage 3 The result you get is MIMe data that you can make "number of video frames" repeated calls to gteMIMefund() with to get the animation of that linear segment to spread over n frames. I assume that's what Gerrit's trying to achieve by dividing the p scaler by 4 and doing repeated calls to gteMIMefunc() - that should work by the way, RsdANIMlib does that and it works a treat. I reckon that Gerrit using ONE as a p scaler is far to big and accounts for the problem - there's some math error going on in what should be the fractional part of the delta information (the GTE is prone to errors in the fractional component). So what he actually should do is scale his delta array up as far as possible without overflowing the +/- 32767 that you can get in a signed short and reduce the p scaler accordingly (multipy all delta's by 10, divide p scaler by 10 seems a good starting point). > James Say thankyou Master ;) Craig.