Path: chuka.playstation.co.uk!news From: alex@teeth.demon.co.uk (Alex Amsel) Newsgroups: scee.yaroze.programming.3d_graphics Subject: Re: Help: GsSortObject4 & GsSortOT Date: Thu, 23 Oct 1997 14:11:42 GMT Organization: Into Beyond Lines: 39 Message-ID: <34505a1f.398393@news.playstation.co.uk> References: <344e12ea.11334163@news.playstation.co.uk> <344E2A0F.15B5@interactive.sony.com> Reply-To: alex@teeth.demon.co.uk NNTP-Posting-Host: teeth.demon.co.uk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Newsreader: Forte Agent .99g/32.335 On Wed, 22 Oct 1997 17:30:07 +0100, Developer Support did quoth at me: >No, it doesn't work. The field exists for future implementation. Shit. Anyone got a neat & quick mips sqr implementation by any chance? >The worlds 16bit, I take it 600 is the distance you want the small OT >from the viewpoint, and the large OT is 11bit. So 600/(65536/2048) = >18.75 the value to include the little OT at. The number seems about right. >Gs divides the entire 16bit world into sections for the OT, so each OT >section in your case is 32 wide. The start and end of the the objects >within the world makes no difference at all. I've misunderstood how the internal gs code is working. So if my OT length is 14 (the maximum allowed), the OT actually allows Z values up to 65536 and AUTOMATICALLY shifts all the Z values by 2. And when inserting OTs into each other, gs AUTOMATICALLY takeas account of the 'length' of the target OT. That makes sense. Wish I'd realised before, I can modify a couple of my OTs now :) Regards, Alex Amsel + Tuna Technologies + Telephone & Fax +44 (0)114 221 0686 + + For all your Win95/NT/Console Game and Tool Development + + And we say, "A good programmer always blames Microsoft" + + I proclaimed "Bring back the Doog!", and so it was done +