Path: chuka.playstation.co.uk!news From: developer support Newsgroups: scee.yaroze.programming.3d_graphics Subject: Re: GPU Code xxh not supported Date: Fri, 04 Jul 1997 15:44:15 +0000 Organization: PlayStation Net Yaroze (SCEE) Lines: 34 Message-ID: <33BD1A4F.892@interactive.sony.com> References: <5pga0c$8c3@chuka.playstation.co.uk> <33BBB432.FF5@interactive.sony.com> <5ph02c$8c4@chuka.playstation.co.uk> <33BCB28A.6366@interactive.sony.com> <5pis12$8c5@chuka.playstation.co.uk> NNTP-Posting-Host: 194.203.13.9 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.01 (Macintosh; I; PPC) Matrix Games wrote: > > Hi there, > > I find it very worrying that someting as blatantantly useful as true > 3D lines would not be supported by playstation hardware. Also > below you say 'another one thats not supported'. What are the > other types and their respective codes?? I suppose I could just > iterate through them and test with GsLinkObject4. A point to note by > the way is that it is GsLinkObject4 that throws a wobbly. When I set > up GsDOBJ2 with my own code (g.tmd = ... ) I do not get any errors > but nothing is displayed, so maybe it is just GsLinkObject4 that is > dumb (or smart depending on which way you look at it). > > And while I am here, what exactly do > (1)GsMapModelingData, > (2)GsLinkObject4 and > (3)GsInitCoordinate2 really do? > > Not much I would say. > 1: set .flg to 1, claculate full address pointer of primitives, > normals and vertices from tmd base address and their stored offsets. > 2: set .tmd to top of data > 3: set coord2->coord to GsIDMATRIX > and coord2->super = WORLD or whatever coordinate system is > the parent in the object hierarchy. > None of the light sourcing with gradation works. This seems to be more to do with the fact that the mode numbers are used for no gradation but with a different option number. 1,2 and 3 do exactly as you describe, saves writing your own macro I suppose. Stuart