Path: chuka.playstation.co.uk!news From: Developer Support Newsgroups: scea.yaroze.programming.3d_graphics Subject: Re: Messing with the primatives Date: Wed, 20 Aug 1997 08:18:55 +0100 Organization: PlayStation Net Yaroze (SCEE) Lines: 31 Message-ID: <33FA9A5F.2DD5@interactive.sony.com> References: <33F27552.437C2A01@ix.netcom.com> <33FA317F.3279@chat.carleton.ca> NNTP-Posting-Host: 194.203.13.10 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.01 (Win95; I) Tim O'Neil wrote: > > One thing I've been wondering about .... > > If you display these primitive values (olen, ilen) before they are > linked via GsLinkObject4 (or whatever it is), they correspond to the > values that you set them to, but if you go into the 'tmd' pointer of the > GsDOBJ2 structure and grab them after they have been linked, these two > values are changed. It only seems to modify the very first primitive > packet for a given tmd header. Was just wondering what this represents, > because it is the only thing that is keeping me from bypassing that > routine. > I suppose another thing that makes me wonder about it is that even if > you go in later and change the data in the primitive all around (save > the stuff that has been modified) it will still work fine, but if you > hammer these values back to what they were it will bomb. Maybe its just > me, but who knows. Hi, The changes to olen/ilen are part of the optimisations to improve the speed of SortObject. What happens is that a count of similar primitives is produced so that instead of deciding on a primitive basis the routine can dispatch a group of 20 FT3's to be rendered more rapidly. This has a side effect that a mixed TMD will actually render more efficently if the packets are 'sorted' Cheers, Colin.