Path: chuka.playstation.co.uk!news From: "Alex Herbert" Newsgroups: scee.yaroze.freetalk.english Subject: Re: Newbie needs basic help Date: Tue, 20 Nov 2001 14:16:27 -0000 Organization: PlayStation Net Yaroze (SCEE) Lines: 118 Message-ID: <9tdogl$4q11@www.netyaroze-europe.com> References: <9t4jt2$ob41@www.netyaroze-europe.com> <01c16fc2$8b592ba0$2f3be4d5@pal-s-omnibook> <9t76in$ob42@www.netyaroze-europe.com> <9tb0qt$iq1@www.netyaroze-europe.com> <01c171b1$2115a020$2d2c1bd4@pal-s-omnibook> NNTP-Posting-Host: host213-123-133-136.in-addr.btopenworld.com X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Hi pal, GsOT_TAG is a GPU packet header. (A GPU packet, or primitive, is what tells the GPU to draw a sprite or a triangle, whatever.) All GPU packets start with a GsOT_TAG. Of the two components of the GsOT_TAG (page 19, Lib Ref manual), 'num' is the length of the attached packet data, and 'p' is a pointer to (i.e. the address of) the next packet. Imagine we have a short OT with an OT_LENGTH of 2, giving us just 4 positions on the z-axis. Let's forget double buffering for now and just have a 1 dimensional array: GsOT_TAG Tag[4]; Now, when we call GsClearOt(), it does the following: The 'num' component of each tag is set to 0 as there is no GPU drawing data attached. (They are essentially empty packets.) Then the 'p' components are set so that Tag[3] holds the address of Tag[2], Tag[2] points to Tag[1], Tag[1] points to Tag[0], and Tag[0] points to zero to indicate the end of the list. Something like this: Tag[3].p = &Tag[2]; Tag[3].num = 0; Tag[2].p = &Tag[1]; Tag[2].num = 0; Tag[1].p = &Tag[0]; Tag[1].num = 0; Tag[0].p = 0; Tag[0].num = 0; Now, if we were to call GsDrawOt(), the GPU would start drawing the packet at Tag[3], but as the packet length is zero, it will finish very quickly. Once the GPU has finished drawing that packet, it will look up the address held in Tag[3].p and move on. This repeats until a pointer to zero is encountered, at which point drawing is complete. The result of this is that the GPU will whiz through the OT but draw nothing. Everything is in reverse order by the way because the GPU needs to draw the objects furthest away first. OK, so what happens when we sort a sprite into the OT, with a priority of 2 for example? Well first, a sprite packet is constructed in the packet workspace (as set by GsSetWorkBase()). This new packet will consist of a GsOT_TAG, a GPU sprite instruction and the sprite data (screen and texture co-ordinates, etc). For now I'll refer to the GsOT_TAG in this new packet as 'NewTag'. To link the new packet into the OT, first NewTag.num is set to the length of the packet. Then the address stored in Tag[2].p (because we're sorting the sprite at priority 2) is copied into NewTag.p. (Note, this is the address held in Tag[2], not the address of Tag[2].) Then NewTag.p is set to point at Tag[2]. This has the effect of inserting the sprite packet into the chain, so now: Tag[3] points to Tag[2], Tag[2] points to NewTag, NewTag points to Tag[1], Tag[1] points to Tag[0], Tag[0] points to zero. Magic! I'm sure you can work out what happens now when we call GsDrawOt(). As you can see (hopefully), the original framework array of GsOT_TAGs acts as nothing more than a convenient list of insertion points into the OT. So to answer your question, yes, the data in the GsSPRITE structure is copied when you sort it. The GPU packet format is nothing like the GsSPRITE structure though so it's not a direct copy. There is no relation between the size and format of any GPU packet and the library structure used to create it. GPU packets are packed in a GPU friendly format, whereas the library structures are programmer friendly. Out of interest, you might want to check out the File Formats document (available at the NY website), in particular the format of TMD primitives. Whilst these are not actual GPU packets (because they are 3D rather than 2D) they are very similar in structure to GPU packets and share many of the same components. I hope I've made things a little clearer. Alex "pal" wrote in message news:01c171b1$2115a020$2d2c1bd4@pal-s-omnibook... > Hi Alex, > I've been afraid to ask for long but apparently now is a good time and you > are the right person to ask :) (of course, anyone else is welcome too!) > > - What are those mysterious GsOT_TAG's, and what do their two fields mean? > They're still pretty weird to me. > > - What happens when you register something in an OT? Does it get copied? I > think it gets copied (but where? maybe in the array passed to > GsSetWorkBase?) because it is possible to use the same GsSPRITE to display > a sprite at various positions; e.g.: > > GsSPRITE sprite; > ... > sprite.x = x1; > GsSortFastSprite(&sprite, ot, pri); > sprite.x = x2; > GsSortFastSprite(&sprite, ot, pri); > > this code does display two sprites, although the first one should be lost > if not somehow copied by GsSortFastSprite. > > What really bothers me is that this copying process must be uselessly > time-consuming, so I can't believe it's really done this way... or is there > another way that I missed? > > pal >