Path: chuka.playstation.co.uk!chuka.playstation.co.uk!chuka.playstation.co.uk!not-for-mail From: George_Bain@Playstation.sony.com Newsgroups: scee.yaroze.programming.3d_graphics Subject: Re:GsSortOt() Date: 17 May 1998 16:45:38 +0100 Organization: Sony Computer Entertainment Europe - 119.SS5 Lines: 84 Sender: news@chuka.playstation.co.uk Message-ID: <6jn0n2$3771@emeka.playstation.co.uk> Reply-To: George_Bain@Playstation.sony.com NNTP-Posting-Host: emeka.playstation.co.uk via smtpd (for [194.203.13.2]) with SMTP; 17 May 1998 15:50:25 UT by camsg001.camb.scee.sony.co.uk (8.8.6/8.8.6) with SMTP id QAA12762 for ; Sun, 17 May 1998 16:48:37 +0100 (BST) From: George_Bain@Playstation.sony.com To: news@playstation.co.uk Content-Disposition: inline Hi there, My good buddy James here explained this pretty damn good. Here is the transcript. Regards, George@SCEE > I guess I >have misunderstood. I thought that the OTs I sorted into the main OT were >still used and just referenced by the main OT. Is this wrong? No, that's right. They are referenced in the reverse order that you insert them. > Are the primitives from the OTs sorted into the main OT? No. > Could someone explain what is going on? Gladly. An OT is a just a linked list of GPU primitives, and GsSortOT simply inserts the Source OT into the Destination OT at a specific place in the Destination OT's linked list. No extra sorting or copying is performed, it's just a simple Comp. Science 101 insertion of a linked list into another linked list. The key to __where__ the source linked list is inserted is contained in the source's GsOT.point field. This is supposed to be a 'typical value of Z', a rather fuzzy definition unfortuately. The GsOT structure contains an array of size "2^GsOt.length" which are all (initially) consecutive elements in the linked list. Their fixed position allows the GsSortObject() to easily insert new primitives at the appropriate Z resolution. When you do a GsSortOT(), it inserts the source OT linked list into the destination OT linked list, at a Z resolution specified by the source's GsOT.point field. So it's like all the polygons from the source OT (sorted amongst themselves) being inserted at a single Z resolution in the destination OT. Say your destination OT has a length of 10, so the OT is an array 2^10 long which gives you a Z-resolution of 1024 different values. If your source GsOT.point = 100, then it will be inserted into the destination OT at a Z resolution of 100. Which implies a restriction - the source's GsOT.point value must be less than "2^destGsOT.length", otherwise the program will index out of range and possibly crash! Just to complicate things: 1)The position at which it is inserted is __actually__ sourceGsOT.point - destGsOT.offset, but since offset is usually 0 for most people so I've ignored it. 2) The start of the source linked list is considered to be sourceGsOT.tag, NOT sourceGsOT.org. Cheers, James Russell@SCEE >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> From: "Roland Boettcher" Hi, I'm having problems with GsSortOt(). Can someone give me some info or an example? Roland