Path: chuka.playstation.co.uk!news From: Chris Chadwick Newsgroups: scee.yaroze.beginners Subject: Re: Displaying a sprite Date: Mon, 23 Mar 1998 02:09:02 -0800 Organization: PlayStation Net Yaroze (SCEE) Lines: 34 Message-ID: <351634BE.AE6@dial.pipex.com> References: <351380C8.73EA@aol.com> NNTP-Posting-Host: an202.du.pipex.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.02 (Win95; I; 16bit) Hi Scott, I've just taken a quick look at your code and I think your problem is that the packet buffers aren't big enough. The line: PACKET packetArray[2][Num_Sprites * sizeof(GsSPRITE)]; This only gives the size of a GsSPRITE object for each buffer which is enough for when you dont use a GsSortClear(), but when you do there isnt enough buffer space since GsSortClear() adds a primitive to the drawing command list, just like any other 'sort' does... I seem to recall seeing the above line of code in someones tutorial source - to me it's mis-leading. Each primitive sorted into the packet buffers won't simply be the same size as a GsSPRITE. In fact, I find that non-scaled, non-rotated sprites use 24 PACKETS(bytes) and scaled/rotated sprites use 40 PACKETS. I believe a sprite with scaling or rotation is actually added to the packet buffer as a flat, texture-mapped polygon primitive. 24 PACKETS seems to be the accepted primitive size to use when defining your buffers, but since some primitives can be larger than this, its always a good idea to make your buffers somewhat larger than simply 'num_sprites * 24'. Something like: '(num_sprites+50) * 24' might be in order since we are talking only 24 bytes per primitive! Hope this helps and that I havent missed something else in your code. Cheers, -Chris