Path: chuka.playstation.co.uk!news
From: Alex Herbert <aherbert@ndirect.co.uk>
Newsgroups: scee.yaroze.beginners
Subject: Re: GpuPacketArea query.
Date: Tue, 30 Jun 1998 17:58:24 +0000
Organization: PlayStation Net Yaroze (SCEE)
Lines: 26
Message-ID: <35991930.333A683@ndirect.co.uk>
References: <35557807.6E248247@chowfam.demon.co.uk> <3558DF85.7C89DA42@ndirect.co.uk> <3559D87E.D5C1EBD1@chowfam.demon.co.uk> <3594C013.116@manc.u-net.com>
Reply-To: aherbert@ndirect.co.uk
NNTP-Posting-Host: dialin2-39.ndirect.co.uk
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 4.04 [en] (Win95; I)



James Shaughnessy wrote:

> PS I still use the old formula for packet space:
> PACKET GpuPacketArea[2][NUM_SPRITES*sizeof(GsSPRITE)];
> "sizeof(GsSPRITE)" is a macro unless I'm very much mistaken.
> Usually when I don't allow enough for NUM_SPRITES I get wierd effects
> like flickering sprites.  It is amazingly difficult to actually get
> the PlayStaion to crash, I find!

Maybe I'm missing something here, but I didn't realise that there was any
correlation between packet sizes and the size of the GsSPRITE structure.

Personally, I allocate say 64K of space for each packet buffer using
malloc().  Then, after sorting all objects (just before I DrawSync()) I
check out how much actual memory space is used, by subtracting the result
of GsGetworkbase from the address used for GsSetworkbase.  (I think that's
what the functions are called.)  By keeping a running peak value for memory
usage, I know exactly how much memory is required, so I can reduce the size
of the packet buffers if memory starts to get tight.


Herbs