Path: chuka.playstation.co.uk!scea!greg_labrec@interactive.sony.com
From: sramsay@smart.net (Scott Ramsay)
Newsgroups: scea.yaroze.programming.2d_graphics
Subject: Many, Many sprite questions  (long)
Date: Thu, 01 May 1997 03:30:41 GMT
Organization: SCEA Net Yaroze News
Lines: 70
Message-ID: <5k92j6$9a35@scea>
Reply-To: sramsay@smart.net
NNTP-Posting-Host: ppp80.bcpl.lib.md.us
X-Newsreader: Forte Free Agent 1.0.82

Hi fellow Net Yaroze members,

 I've been working with the 2D aspects of Net Yaroze for about a week
now.  I've just about experimented with all of the 2D api functions.
There are many things I've discovered or don't understand that are
not mentioned anywhere in the manuals.  Hopefully someone here
can clarify the below items:

1.  What is the maximum size of a sprite? It looks to be 256x256. One
texture page? Are there any other limitations for sprites not
mentioned in the manuals?

2. What exactly defines a texture page for a sprite?  In the "User
Guide - Polygon Drawing"  p.17, images and texture patterns are
stored in 256x256 pixel pages. But according to the API function
GetTPage, texture pages are 64x256?

3. Does sprites overlapping across a 64x256 texture page slow
down drawing? e.g.   Specifing a GetTPage texture addres of (0,0)
then using a high (u,v=255,255)  value for the sprite.

4. What is a typical/proper method of copying a static full screen
background per game loop?  Many samples I've seen load RGB 
data/TIM file to the display buffer, and "GsSortSprite" based on the
loaded area.  An obvious method would be "MoveImage" to the non-
seen area of the GPU buffer. Yet I haven't seen any examples.

Alot of the above questions arised when I was working a tile map 
function like GsSortFixBg16 which supports any size tile of a power of
two (2,4,8,16,32...). The function worked fine when I was testing it
with one of my tiles. When I  tried with any other tile, I noticed a
big decrease in performance.

Here's the setup:

1. Graphic mode setup -
	GsInitGraph(320,240,GsOFSGPU|GsNONINTER,1,0);
	GsDefDispBuff(0,0,0,240);

2. 8 bit TIM file 256x256 loaded in the display buffer at (320,0). Its
CLUT loaded in the display buffer at (0,480). (just below the flip
pages)

3. Four 32x32 tiles in the above 256x256 texture at (u,v) offsets of
(0,202), (32,202), (64,202) and  (96,202)

4. An array of GsSPRITE large enough hold all the displayable
tiles. At least ((320/32) * (240/32)) GsSPRITE elements. The 
four tile GsSPRITES structures are copied to the array for displaying.

When I display the grid of sprites using only the sprite (0,202),
the panning is fast and pretty smooth.  The problem aries when
I use any of the other 3 tiles.  For example, if I only use tile
(32,202), there is a visual slowdown.

Ok, so I think its a GetTPage problem or its my code accessing any
sprites other than the first tile.   So I ONLY change the last 3 tiles
(u,v) coordinates to  (0,202-32), (0,202-32*2) and (0,202-32*3).  Now
the code works perfectly and fast in any situation.  

I've check the GetTPage value and verifed that each sprite has the
closest (x,y) texture page address.  I have a function that 
properly aligns the (x,y) values for GetTPage and (u,v) for sprites.
The only other thing I can think of is some cache problem where the
sprites are aligned.

-----
  Scott Ramsay
  sramsay@smart.net