Path: chuka.playstation.co.uk!news
From: SCEE Developer Support <dev_support@interactive.sony.com>
Newsgroups: scee.yaroze.programming.2d_graphics
Subject: Re: Sprite Z Ordering
Date: Tue, 22 Apr 1997 11:22:02 +0100
Organization: Sony Computer Entertainment Europe
Lines: 53
Message-ID: <335C914A.264E@interactive.sony.com>
References: <01bc49e3$259ecfe0$250ce8c3@cma> <3354CA83.3A4A@interactive.sony.com> <335C98E9.67BA@dial.pipex.com>
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)

Chris Chadwick wrote:
> 
> Hi Lo,
> 
> SCEE Developer Support wrote:
> > The values for the size of the PACKET arrays are partly
> > arbitrary; basically, every primitive requires up to
> > 24 PACKETS; and the PACKET scratchpad must be enough
> > for all the primitives we want to draw. Given we don't want to
> > have to calculate the exact number each time, we just set
> > an upper limit, hence you may often see sample code
> > like this
> >
> > #define PACKET_MAX1 24    // max number of packets per primitive
> > #define PACKET_MAX2 2048  // max number of primitives we want to draw
> >
> > PACKET GpuPacketArea[2][PACKET_MAX1 * PACKET_MAX2];
> 
> What actual information is contained in the 24 PACKETS(bytes) of each sprite primitive?
> I *had* thought it might comprise a copy of the GsSPRITE object registered in the
> OT with GsSortFastSprite(), plus a pointer to the next primitive in line but, by my calculation,
> all the members of a GsSPRITE object add up to 22 bytes, leaving only 2 bytes for the pointer!
> 

The data stored in the GPU packet buffers is in a format
that I don't know, have never needed to tinker with,
and which isn't useful to know. 


> Also, why are GsOT_TAGS defined as two bit-fields (unsigned p:24 and unsigned char num:8)?
> I thought just a normal (32bit) pointer would be used - although I suspect this has something to
> do with the three CPU logical address spaces used to map the 2MB of physical memory (maybe!?).
> 
> Sorry, but I had never heard of Ordering Tables until I got my Yaroze (there, I've admitted it :)
> All the details please someone!
> 
>         Cheers
> 
>                 Chris


Ordering tables are a way of ordering everything w.r.t value;
you specify N different Z levels and the OT discriminates to that
extent. It's really an array where each item is a list.

It's honestly not worth looking into the detailed
implementation w.r.t. OT_TAGs; it doesn't tell you anything,
or provide faster/less-memory/more-flexible access.

Many standard 3d graphics books will talk about techniques
basically indentical to ordering tables, under a different name.

Lewis