Path: chuka.playstation.co.uk!news
From: "Alex Herbert" <alex@herbs.dabsol.co.uk>
Newsgroups: scee.yaroze.freetalk.english
Subject: Re: Packet Explanation
Date: Fri, 23 Nov 2001 13:00:12 -0000
Organization: PlayStation Net Yaroze (SCEE)
Lines: 85
Message-ID: <9tlh4b$dq95@www.netyaroze-europe.com>
References: <9tkp3s$dq91@www.netyaroze-europe.com>
NNTP-Posting-Host: host213-123-132-202.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 Greg,

The packet area is just a chuck of memory, so as long as it's big enough to
hold all the packets you create then fine.  It doesn't really matter how you
define it but declaring an array seems to be the most common way.

The NO_SPRITES*sizeof(GsSPRITE) method seems logical at first as this would
suggest that the packet area is the correct size to hold the number of
sprite packets as defined by NO_SPRITES.  However this is wrong as the size
of the GsSPRITE structure has nothing to do with the size of the packets
created.  For this reason I wouldn't advise doing it this way.

The PACKETMAX*24 method makes a little more sense to me as 24 is an average
size for a GPU packet.  Some are bigger, some are smaller but 24 is good as
a rough guide.  As for how a value for PACKETMAX is chosen, well that's up
to the programmer to decide.  Picking a value of 2048 for example is saying
that you definitely won't be sorting more than 2048 items (roughly) into the
OT.

Or you could just declare it like this:

#define    PACKETAREA_SIZE    32768        // 32Kbytes
PACKET    packetarea[2][PACKETAREA_SIZE];

and just specify the number of bytes required.  Choosing a big(ish) number
like 32K is a good starting place.  This number can then be refined
throughout development as you get a better idea of how much space is
actually required.  Calling GsGetWorkBase() after sorting all your objects
(i.e. just before you call GsDrawOt) will return the address of the next
free byte in the packet area (one byte beyond the used area).  So, simply
subtracting the start address of the packet area will tell you how much
memory is being used.  Sorted!

Alternatively, instead of declaring an array for the packet workspace, you
could assign memory from the heap at run-time using malloc().  Or if
memory's getting tight, you could set the address of the packet workspaces
to the area of memory where you loaded your TIMs.  Once the TIMs have been
loaded into VRAM the chances are that you don't need the copies in main RAM
any more, so overwriting them with GPU packets isn't a problem.  At the end
of the day it's up to you to use the method which you feel is the most
appropriate.

Alex


"Greg Cook" <gjc53@student.canterbury.ac.nz> wrote in message
news:9tkp3s$dq91@www.netyaroze-europe.com...
> Ok well ive been working through various beginner tutes, and have been
> reading the beginners forum to get some help and explain some things.
>
> But i have a question about Packets.  In most tutes there are two distinct
> ways to define the Packet Area and im unsure which is the correct way to
do
> it..
>
> 1.
>
> #define NO_SPRITES 1
>
> static PACKET packetarea[2] [NO_SPRITES*sizeof(GSPRITE)];
>
> 2.
>
> #define PACKETMAX 2048
> #define PACKETMAX2 (PACKETMAX*24)
>
> static PACKET packetarea[2][PACKETMAX2];
>
> so which one is correct? and in the second version where does the magic
> number 2048 come from? i assume the 24 is something to do with the size of
> the items in the structure... but is 2048 just a magic number as i have
seen
> it defined as 1024 and various other sizes...........
>
> ok well yet another question from me..
>
> thanks guys
>
> Greg
>
>
>
>