Path: chuka.playstation.co.uk!news
From: asc@netlink.ch (Yannick Suter)
Newsgroups: scee.yaroze.programming.3d_graphics,scea.yaroze.programming.3d_graphics
Subject: Re: gteMIMefunc & me: One of us is wrong
Date: Sun, 20 Dec 1998 19:41:11 GMT
Organization: Nowadays
Lines: 29
Message-ID: <367d4d8e.508235@news.playstation.co.uk>
References: <364A002A.62D2@funnytown.com>
Reply-To: asc@netlink.ch
NNTP-Posting-Host: pppw52.netlink.ch
X-Newsreader: Forte Free Agent 1.1/32.230
Xref: chuka.playstation.co.uk scee.yaroze.programming.3d_graphics:1087 scea.yaroze.programming.3d_graphics:329

>- Could this a problem with the PSX's fixed-point math? (Inaccuracies
>building up to a high level of nastiness?) My models are around 500
>'units' in width/height, but there isn't any easy way for me to make 'em
>bigger.

I had the same prob.. finally i wrote my own routines (not as fast as
gteMIMefunc but for the moment enough for me). i think the prob is
here is really the fixed-point math.

little example: (1dimens)

startPoint: 0 endPoint: 10 diff: 10

interpol using 1 interpolationStep - everything will be fine.. 

interpol using 4 midSteps (p is here a float which goes for 0 to 1 ..
not like in the gteMIMefunc, but at the end the same)

1. step: diff * 0.25 = 2.5 (the prob is simplified - i know - but
again, at the end the same)

coz the func use fixpoints, 2.5 should get 2 or 3.. 

ok.. 4 steps: each will add 2 or 3 to the sourceCoord, so we'll end
at the coord 8 or 12.. quite far from 10 =)

Yan